I've use this method recently. Our VM service is based on libvirt, which doesn't support QEMU socket type interface natively, so I need to add the following to the XML:
After initially being keen on running qemu directly, I've really come to appreciate libvirt, even thought you do have to be willing to peer past all the XML...
Mostly because it is only partially documented, on a few RedHat pages. This is where GPT shines because it is able to make something better from the incomprehisible mess of RedHat.
Does xml suck. Meh yea it mostly does. Was it a crappy format for everything. Yes, XML over the wire, not so great.
Would I rather have xml configs than yaml, or json... The more I think about it, yes, I would.
1. The dom sucks in a browser, it's gross when it gets huge. If your config files are THAT large then, we have OTHER problems.
2. Validation. It validates. Not only on a syntax level (is this document complete, does it have a final close tag). You can also run checks against a DTD, an xml schema and XSD(??? its been a while, I think this was a way).
3. XSLT: I have mixed feelings on this, but there was a way to merge, change and transform... IT was powerful and testable, way better than templated config files.
Maybe I am looking at it wrong, maybe this is me having rose colored glasses for an ex. But I sure would like all those features BACK.
All of these exist for json, and since yaml has the same object structure as json these tools can mostly be reused
1. Plain old hash maps and arrays. No special stuff required
2. JSON schema exists and works pretty well
3. JSON path and json patch cover this. Though because json follows a plain object model there just isn’t as much need.
Contrary to xml having clean object structure and not having to worry about using nested data or props makes all of the above easier and require fewer special tools. Additionally in the qemu example you can see problems with xml right away look at this extra “qemu:” structures, yay more stuff to parse. Then the args come in as repeated elements, are those an array or not?
Slightly related, I remember reading once of malware that uses a virtual machine running TinyXP[0] to obfuscate itself from the host OS. The footprint of TinyXP is tiny compared to the latest versions of Windows and runs on very little RAM, and gets past reverse engineering ploys which aim to unravel what the malware does.
That's software not installed by default but available on the ISO, should you decide to install it.
Earlier ISOs of TinyXP were less than 150 Mb in size.
The "MicroXP" variant (also from the same ISO) installs in <10 minutes and takes about 250 Mb if you disable the page file. It can even be reduced a bit more if you know you're not going to use some components (e.g. a browser), I assume.
This reminds me of the Australian National University hack, where the threat actor downloaded and spun up their own XP/Kali VMs on servers they compromised
The article mentioned that it was used to gained a large company so I’m sure that was a huge benefit for the attacker. A lot of other tunneling mechanisms might have been blocked and easy to overlook QEMU.
Main thing that comes to mind is code signing and executable reputation. Here's my understanding: an unsigned exe on Windows throws up scary warnings to users before it will run, until that specific exe is trusted by enough users and added to some central database. If you signed with a legit EV certificate (at least ~$400/year) it's trusted implicitly and no warnings. If you sign with an OV[0] it will give warnings until the cert is trusted, but you can then use the cert to sign new exes (ie updates to the program).
I just ran `osslsigncode verify qemu-w64-setup-20231224.exe` and it appears it's signed but the 1 year cert expired in December 2023. Still, I would expect that QEMU releases tend to be trusted fairly quickly assuming a decent number of users.
[0]: open source options available for free[1] or ~$50/year[2]. If you get your app on the Microsoft App Store, they'll sign it for you which is also free ($19 lifetime account IIRC).
the company-system had a qemu "client" that opened up a connection to the attacker's IP (1 MB ram, no disk space, just tcp socket); the attackers then used qemu on their own systems, listening to the tcp-connect from the compromised system, in order to establish a tunnel.
securelist.com also states the tunnel made by qemu is not encrypted
AFAICS, other than easy point to point tunnel via twin VM instances
the win here was the TCP encapsulation. The investigators had to strip
that back using pcap edit, so presumably it wasn't an easy spot for
the firewall either.
sorry noob q, but do you mean that the company probably didn't think to search for the unencrypted traffic? I'm not sure if I understand why the encapsulated traffic being unencrypted is "advantageous" for the adversary
I think it's just that most scanning tools aren't trying to unwrap a TCP packet inside a TCP packet, so it bypassed their naive filters. Once a researcher spotted it, it was trivial to unwrap, but automated tooling would just see it as the outer TCP packet with some opaque data inside of it.
I would assume that the attacker's destination IP would show up on some dashboards somewhere though...
The VM itself was presumably idling on a BIOS "no bootable device" prompt. I don't think QEMU has an option to not start the VM at all and just do networking.
This case exemplifies the importance of a layered security approach, integrating endpoint protection and network monitoring, to effectively combat such stealthy techniques.
In this way, I can create a L2 tunnel from remote site to the VM, also keep the VM untainted.