I have it running locally, and i don't want to add credentials to the vm with the malware.
According to qwen:
It's cross platform
It has a bunch of persistence mechanisms.
It downloads another pack from pub-1fe39d600a4447ba895ef1c848d32e7e.r2.dev, Verified I got the secondary payload
This pack looks like a python 3.10 environment along with an executable called cupsd.
And downloads another js script from http://138.201.125.58:1224/client/99/77
That script then proceeds to download three python scripts that use the aforementioned python environment and do their business, qwen is having trouble de-obfuscating their urls and I am busy.
Also what is your go to OS?
Hm, when I think of it an old Raspberry Pi could be my go to for this, but always physically.
> I'm actually curios to know how do you people visit the link securely?
Disposable vm with a connection to tor. Then copied to a disposable vm with access only to one port on my llm server the one running llama.cpp.
> I guess a VM but could in theory something be resilient enough to misuse the Shared Clipboard or something to access your host machine?
When I am doing this kind of thing i have some rules.
Rule #1 Do not run the malware.
Rule #2 No copying from the analysis vm.
Given the malware is not run it's highly unlikely that any Xen vulnerabilities can be exploited or llama.cpp vulnerabilities for that matter.
Ideally I would not be using my own llm server but proxying the requests through another vm that contains temporary credentials to a llm provider. But I did not have the time to set that up.
> Also what is your go to OS?
Qubes OS
> Hm, when I think of it an old Raspberry Pi could be my go to for this, but always physically.
Physical isolation has it's own issues. If you don't airgap the device it could exploit other devices in your network, old residential routers are not exactly bulletproof especially from the lan side. Additionally, physical devices could be vulnerable to bios and UEFI firmware persistence mechanisms.
