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