5 ms·

Network Tunneling with QEMU

187 points by rrampage 3y ago

actionfromafar 3y ago
So nothing actually ran on (one of) the Qemu?
- out-of-ideas 3y ago
  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
  - nonrandomstring 3y ago
    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.
    - cckk 3y ago
      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
      - chatmasta 3y ago
        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...
- eqvinox 3y ago
  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.
  - rwmj 3y ago
    You can use -S. There's still a guest but it doesn't start the virtual CPU running. It would make no practical difference for this "use case" though.
    - out-of-ideas 3y ago
      the article has examples of QEMU cmds ...
titannet 3y ago
I don't see the benefit for the attacker besides novelty. Am I missing something?
- mschuster91 3y ago
  The benefit is that it won't readily show up on an audit like an iptables backdoor would.
  - tsujamin 3y ago
    Yeah like all the above IMO the tool is already on the machine and it’s not a typical (read: looked for) technique
- Bluecobra 3y ago
  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.
- adql 3y ago
  not looking suspicious in ps aux maybe ? at the very least if you hacked into VM hypervisor
- unixhero 3y ago
  Offensive security through obscurity? I don't know
- apitman 3y ago
  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). [1]: https://signpath.org/ https://signpath.org/ [2]: https://shop.certum.eu/data-safety/code-signing-certificates.html https://shop.certum.eu/data-safety/code-signing-certificates...
ytch 3y ago
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: <qemu:commandline> <qemu:arg value='-netdev'/> <qemu:arg value='socket,id=mynet0,listen=10.6.0.1:12200'/> <qemu:arg value='-device'/> <qemu:arg value='virtio-net-pci,netdev=mynet0,id=net1,mac=58:a4:c0:a8:bf:51,bus=pci.0,addr=0x3'/> </qemu:commandline> On the other endpoint, a Linux TAP tunnel daemon is responsible for encapsulating packet to the Length-Value data as the article said. In this way, I can create a L2 tunnel from remote site to the VM, also keep the VM untainted.
- yrro 3y ago
  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...
  - zer00eyz 3y ago
    >> willing to peer past all the XML 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.
    - bbatha 3y ago
      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?
favourable 3y ago
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. [0] https://archive.org/details/tiny-xp-rev-11 https://archive.org/details/tiny-xp-rev-11
- tsujamin 3y ago
  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 https://theuniguide.com.au/news/anu-releases-details-of-data-breach https://theuniguide.com.au/news/anu-releases-details-of-data...
- mdaniel 3y ago
  "tiny" ... "I do not think that word means what you think it does": - AllSnap v1.33.2 - Comodo Internet Security v5.0.163652.1142 (requires reboot) - DirectX 9c June 2010 - Everything v1.2.1.371 - Foxit PDF Reader Pro v3.0.1301 - GetDiz v4.4.0.0 - HashCheck v2.1.11 - Prio v1.9.9.2091 - Visual-C++ Runtimes 2005 and 2008 - WinRAR v3.91 and even the Archive entry is tagged 691MB
  - gattilorenz 3y ago
    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.
    - favourable 3y ago
      That's the one. I got them mixed up. Link for it is here: https://archive.org/details/MicroXP-0.82 https://archive.org/details/MicroXP-0.82
bzmrgonz 3y ago
Those sneaky bastards have weaponized QEMU!!
honeybadger1 3y ago
This case exemplifies the importance of a layered security approach, integrating endpoint protection and network monitoring, to effectively combat such stealthy techniques.

187 points by rrampage 3y ago

actionfromafar 3y ago

So nothing actually ran on (one of) the Qemu?

out-of-ideas 3y ago
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
- nonrandomstring 3y ago
  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.
  - cckk 3y ago
    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
    - chatmasta 3y ago
      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...
eqvinox 3y ago
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.
- rwmj 3y ago
  You can use -S. There's still a guest but it doesn't start the virtual CPU running. It would make no practical difference for this "use case" though.
  - out-of-ideas 3y ago
    the article has examples of QEMU cmds ...

titannet 3y ago

I don't see the benefit for the attacker besides novelty. Am I missing something?

mschuster91 3y ago
The benefit is that it won't readily show up on an audit like an iptables backdoor would.
- tsujamin 3y ago
  Yeah like all the above IMO the tool is already on the machine and it’s not a typical (read: looked for) technique
Bluecobra 3y ago
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.
adql 3y ago
not looking suspicious in ps aux maybe ? at the very least if you hacked into VM hypervisor
unixhero 3y ago
Offensive security through obscurity? I don't know
apitman 3y ago
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). [1]: https://signpath.org/ https://signpath.org/ [2]: https://shop.certum.eu/data-safety/code-signing-certificates.html https://shop.certum.eu/data-safety/code-signing-certificates...

ytch 3y ago

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: <qemu:commandline> <qemu:arg value='-netdev'/> <qemu:arg value='socket,id=mynet0,listen=10.6.0.1:12200'/> <qemu:arg value='-device'/> <qemu:arg value='virtio-net-pci,netdev=mynet0,id=net1,mac=58:a4:c0:a8:bf:51,bus=pci.0,addr=0x3'/> </qemu:commandline> On the other endpoint, a Linux TAP tunnel daemon is responsible for encapsulating packet to the Length-Value data as the article said. In this way, I can create a L2 tunnel from remote site to the VM, also keep the VM untainted.

yrro 3y ago
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...
- zer00eyz 3y ago
  >> willing to peer past all the XML 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.
  - bbatha 3y ago
    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?

favourable 3y ago

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. [0] https://archive.org/details/tiny-xp-rev-11 https://archive.org/details/tiny-xp-rev-11

tsujamin 3y ago
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 https://theuniguide.com.au/news/anu-releases-details-of-data-breach https://theuniguide.com.au/news/anu-releases-details-of-data...
mdaniel 3y ago
"tiny" ... "I do not think that word means what you think it does": - AllSnap v1.33.2 - Comodo Internet Security v5.0.163652.1142 (requires reboot) - DirectX 9c June 2010 - Everything v1.2.1.371 - Foxit PDF Reader Pro v3.0.1301 - GetDiz v4.4.0.0 - HashCheck v2.1.11 - Prio v1.9.9.2091 - Visual-C++ Runtimes 2005 and 2008 - WinRAR v3.91 and even the Archive entry is tagged 691MB
- gattilorenz 3y ago
  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.
  - favourable 3y ago
    That's the one. I got them mixed up. Link for it is here: https://archive.org/details/MicroXP-0.82 https://archive.org/details/MicroXP-0.82

bzmrgonz 3y ago

Those sneaky bastards have weaponized QEMU!!

honeybadger1 3y ago

This case exemplifies the importance of a layered security approach, integrating endpoint protection and network monitoring, to effectively combat such stealthy techniques.