台湾 / Taiwan (中/En)
Infosec-specific account for @azakasekai
Taiwanese threat intelligence researcher / VTuber.
Artist: https://twitter.com/jamama_666
Contact: http://stillu.cc/security.txt
| Links | https://links.azaka.fun/ |
| Verification | https://twittodon.com/share.php?t=AzakaSekai_&m=still@infosec.exchange |
| Twitch | https://twitch.tv/azakasekai |
The Taiwan Ministry of Digital Affairs (MoDA) has issued a press release today stating that MoDA was made aware of CHT's improper conduct in March, and have since begun migrating to another Root CA provider (possibly Taiwan CA, another major Root CA that had worked with TW govs).
Meanwhile, CHT has also published a statement and attempting to downplay the situation by claiming "only" Chrome is affected and none of the other browsers like Apple's and Microsoft's (curiously, Firefox was not explicitly mentioned), and that they are "attempting to work with Chrome to get Root CA trust back in March 2026."
Source:
https://newtalk.tw/news/view/2025-06-03/974334
https://www.cht.com.tw/home/enterprise/news/latest-news/2025/0602-1810
Effective July 31st, two major Root CAs used by Chunghwa Telecom will no longer be trusted on Chrome 139 and higher. Chunghwa Telecom is the largest telecommunication company responsible for Taiwan's network infrastructure, and their root CA is used to sign certificates used by major Taiwanese government websites.
Google cited "compliance failures, unmet improvement commitments and the absence of tangible, measurable progress in response to publicly disclosed incident reports."
Finally got around to taking a look at StealcV2 today after a few weeks that it's been out
Initial loader (536a64b3267c5056b261d71324793571d02a8714bcb8f395927f72f77d004f56)
-> CF obfuscated shellcode (bdace8aba0dbcac81811d833605fadc157ed95864537d5bf1fc28f125becef1f )
-> Rust-based (1.85.1) loader/injector (f6ce652432d8baf56195c49d34ad89bd7cf933a6af864973f7b03e6bb3acc88e)
-> StealcV2 payload (a26095cf5fff9a7ec04c3fd3fb60372f38f3dc300addf4983e0ce4f7490ef7b2)
Looks like it might have been a major rewrite? I'm not sure I haven't closely compared it against the StealcV1 yet. Strings are Base64 RC4 encoded. The RC4 patterns used in the binary currently causes false negative in capa at the moment - I've filed an issue accordingly.
We also wrote a new YARA rule to detect StealcV2 on stream as well. Surprisingly, my heuristics-based Chromium ABE stealer YARA rule we wrote half a year ago still matches this sample and other known StealcV2 samples.
C2
- 91.92.46[.]133/8f11bd01520293d6.php
Samples, IoCs, and more
https://github.com/Still34/malware-lab/tree/main/reworkshop/2025-04-26
