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

@helix there are probably more elsewhere, but I'd say there are enough evidences in the Mozilla buglist

It appears there have been numerous compliance failures noted on Mozilla's buglist alone in the last few years. It appears some weren't taking too kindly of CHT's certain resolutions and constant mistakes in recent years.

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."

Solved, it's Tuoni https://docs.shelldot.com

Is anyone familiar with this kind of file name? Looks like it's generated from some sort of C2 framework but I'm not sure what. #threathunting

Just to be clear, it's not like any vendor including us holds exclusive rights to be presenting anything. TAG hasn't done anything wrong - but it sours the mood a little when this is published just few weeks after our talk embargo was lifted.

https://cloud.google.com/blog/topics/threat-intelligence/apt41-innovative-tactics
you're joking TAG completely spoiled our VB2025 talk AAAAA

Does anyone know of the peeps that wrote this article st IBM?
https://www.ibm.com/think/x-force/hive0154-targeting-us-philippines-pakistan-taiwan

Looking forward to presenting at #VB2025 in Berlin this Sept! My colleague and I will dive into a Chinese state-sponsored attack, detailing its FUD XOML execution techniques & the novel use of Google Calendar for C2 communications in an #APT operation.

(Google Calendar C2 is not a new concept - GCR has been around for a while, but this is the first we've observed it in an APT operation.)

Looking forward to presenting at #VB2025 in Berlin this Sept! My colleague and I will dive into a Chinese state-sponsored attack, detailing its FUD XOML execution techniques & the novel use of Google Calendar for C2 communications in an #APT operation.

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

#threathunting #stealc

interesting build script

Just to be clear - I'm not suggesting binary signing is the way to go or the de-facto, but I wanted to see what measures there are to prevent tampered bins from running. Also this isn't a Windows v. Linux debate, Windows has its own large sets of issues as well.

@maubil in many of the incidents we and our peers have seen, they have already EoP'd post-exp with root, and are then replacing core components with tampered ones. My original question was does the system not have some level of validity checks that can ensure the integrity of the binaries. I don't believe this is misleading in any way. As for "the privileged users can do everything," I've seen a few good solutions here that are possibly still resilient under a privileged scenario?

@aloz1 this sounds like a good solution yeah

@qrsbrwn @axel I suppose I just have not run into such systems then. Most of the incidents I've seen of our clients thus far have Linux setups are relatively standard.