Still

台湾 / Taiwan (中/En)
Infosec-specific account for @azakasekai
Taiwanese threat intelligence researcher / VTuber.
Artist: https://twitter.com/jamama_666

Contact: http://stillu.cc/security.txt

Public Key

npub1dvaeulmpehewu000kkfsklutudjvdkd30plug49efns2rdm4fhgs7lx70c

NIP-05 Address

still@infosec-exchange.mostr.pub

Profile Code

nprofile1qqsxkwu70asumuhw8hhmtyct0797xexxmxchsl7y2ju5ec9pka65m5gpl65mt

Author Public Key

npub1dvaeulmpehewu000kkfsklutudjvdkd30plug49efns2rdm4fhgs7lx70c

Show more details

Last Notes

2025-04-26 06:35:38

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
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/402/874/861/396/311/original/2d49d5439f6372d0.png

2025-04-25 04:54:55

interesting build script
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/396/816/158/138/593/original/ed6b675790479229.png

2025-04-24 06:22:19

- reply

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.

2025-04-24 06:03:46

- reply

@nprofile…fe6n 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?

2025-04-24 05:52:58

- reply

@nprofile…q97s this sounds like a good solution yeah

2025-04-24 05:46:21

- reply

@nprofile…ruup ah ok I think this might be feasible then

2025-04-24 05:45:32

- reply

@nprofile…fvus I'll keep this in mind, but I think another problem that stems from this is is every distro either does have something similar or straight up doesn't. I think this makes it extra difficult for guidance when you're dealing with thousands of enterprise users with varying distros.

2025-04-24 05:42:07

- reply

@nprofile…ruup AIDE looks fine, but the problem is it's RHEL exclusive afaik?

2025-04-24 05:39:34

- reply

@nprofile…fvus
#1 does not address the issue of tampered binaries post-installation
#2 is not feasible to monitor on a regular basis

2025-04-24 05:32:08

- reply

https://infosec.exchange/@still/114391292427677855

2025-04-24 05:25:27

- reply

@nprofile…rnuw this is unrelated to what I'm talking about - that code signing only protects the package during/after transit. It does not offer any integrity checks after the binary has been installed (i.e., someone can just tamper with ssh well after it's been deployed).

2025-04-24 05:22:33

- reply

@nprofile…m3qg you can remount the fs as rw if needed afaik long as you have root - which many of these attackers post-exp do

2025-04-24 05:17:44

- reply

The general consensus I'm reading is you're expected to configure dm-verity on a read-only trusted image - which seems like it would require a lot of advanced planning before rolling out such system

2025-04-24 05:02:33

- reply

The reason why I'm asking is I've been reading a couple of reports, and it seems like attackers are comfortable with just going ahead and straight up "sed i/command/command with extra stuff" on existing binaries, or replace critical components/PAM with their own stuff.

2025-04-24 04:57:46

- reply

@nprofile…4aqs that doesn't seem super feasible to monitor

2025-04-24 04:56:51

- reply

From what I'm reading, the user is expected to either a) enable IMA manually in the kernel options (gentoo wiki also says don't use it in prod?) b) install an additional monitoring tool like Tripwire.

2025-04-24 04:46:33

I'm a little rusty when it comes to Linux security, and I think I may have asked this before on Twitter but couldn't get a conclusive answer - is there not any measure that one can take to ensure a binary's integrity on a stock normal Linux distro?
It doesn't seem like the concept of code signing exists on Linux beyond the installation packages - what's to stop someone from modifying the binary post-installation without being noticed? I see there's IMA Appraisal, but that doesn't seem to be enabled by default in the Linux kernel.

2025-03-26 10:01:19

I swear showing of command line in the tooltips used to be the default behavior of Process Hacker - apparently this is turned off by default now in System Informer. Enable the support via EnableCommandLineTooltips in the advanced settings.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/228/151/935/738/912/original/c343bc7733ab0d44.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/228/151/985/521/301/original/47c558404ea24d72.png

2025-03-26 09:07:36

can you call something that overwrites the DLL with a malicious one and then attempt to reload the process to load the DLL "DLL sideloading" still 🤔 I mean it still is technically sideloading from the expected path so... I guess this still counts?

2025-03-25 11:06:55

- reply

I'm fairly sure this feature isn't working for me for some reason, weird

2025-03-25 10:45:51

- reply

- I don't see the shadow account when I do whoami when elevated
- UAC is still showing regular User Account Control prompt
- All token behavior remains the same
am i missing something 🤔
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/222/663/533/772/391/original/5632e0faa3a3a918.png

2025-03-25 09:41:37

Folks who are familiar with Administrator Approval Mode (or Administrator Protection), how do I double check if it's working or not?

2025-02-20 12:08:35

- reply

@nprofile…4yg8 I didn't even get a dump file from that 😭

2025-02-20 11:52:05

turns out creating a new pppoe connection breaks Windows
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/036/069/028/155/302/original/ab21ef839c7dba03.jpg

2025-02-20 03:50:02

I just saw yet another news agency run the whole "MP is using a vulnerability in Windows to hide files!!!" as a legitimate story, when the source still has not disclosed what exactly the problem is and failing to elaborate. It is incredibly frustrating as someone who's been tracking #MustangPanda for nearly 5 years. Here's why I think this is a nothingburger, and people are blowing it out of proportion, and the research is not credible,
- The "vulnerability" is not a vulnerability. It is how desktop.ini works. desktop.ini tells Explorer what properties the folder should contain. This may include things like icon (Logo), folder type (FolderType), name (LocalizedResourceName), and many more.
One of these properties includes CLSID. You can tell Explorer what object the folder should be interpreted as by specifying the corresponding CLSID. For example, {323CA680-C24D-4099-B94D-446DD2D7249E} would correspond to the Favorites folder in Explorer.
The threat group, along with MANY OTHERS, have used this quirk with Explorer to cause Explorer to redirect the folder content to other places, including Favorites, Recycle Bin, and in this case, ActiveX Cache Folder. This is not exclusively used by MP, and has been documented for well over 20 years!
- The research suggests that MP has only recently started using this trick - this is also untrue. They have been known to use this trick since well before PlugDisk became a thing. In fact, they started using this trick all the way back in the early days of late 2010s or even earlier.
- The research mentions that "When files are extracted from compressed RAR files, they are hidden from the user. If the compressed files are extracted into a folder, the folder appears empty in the Windows Explorer GUI."
Yes, because RAR and 7z respects the file attributes created from the source filesystem. In other words, when you compress a folder as System + Hidden, it is going to keep the same S+H attribute when the folder is extracted. Naturally, the user who does not have "Show hidden files" enabled and "Hide protected operating system files" disabled aren't going to see the files.
The research firm also attempted to enumerate the directory via `dir` and it showed no results - because you DIDNT' TELL dir to show hidden files with the `/A:` switch.
- My biggest problem with this research is the sample they linked in the study. The sample they provided is clearly one packed by the victim in Vietnam, and is not used as an initial access. Whilst they never suggested it was used as IA, this is still an incredibly strange example to use because,
1. The sample contains possibly sensitive information (sales data and customer names) from the affected Vietnam firm.
2. The sample does not showcase how PlugDisk could have functioned as-is.
3. The narrative from the research suggested the "vulnerability" all came from this bad RAR file when that is not the case (more on that later).
- The folder you see within the Docusment folder were created by PlugDisk - this folder structure is never used as the first infection factor, nor do they exist on the infected USB drives. This folder is most commonly found in %public%\Publics, but this path can be defined with the PlugDisk config. The desktop.ini is also created by PlugDisk - it does not magically come shipped inside an RAR file.
The whole premise of the research is what ticked me off. This would have been perfectly fine if they were talking about how PlugDisk uses desktop.ini to hide its files, which whilst it wouldn't be anything new, it wouldn't hurt for more people to be more aware of it. Instead, they are going along with the narrative that this was somehow created with a combination of RAR, attrib -s -h, and somehow the victim created RAR file is at fault here.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/034/173/095/498/002/original/ab56e4dc51422bed.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/034/173/263/524/588/original/fdc9fd776d67aaac.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/034/173/281/323/361/original/86c62a9e777fed53.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/034/173/374/934/158/original/8affda3bd5a60b3f.png