With the link I provided, a hacker can use iOS emulated in QEMU for:

  • Restore / Boot
  • Software rendering
  • Kernel and userspace debugging
  • Pairing with the host
  • Serial / SSH access
  • Multitouch
  • Network
  • Install and run any arbitrary IPA

Unlike a locked-down physical Apple device. It's a good starting point.

I'm much more convinced that you're competent in the field of forensics. But I still don't think suspicious network traffic can be categorically defined as a 'device breach.'

For all you know, the traffic you've observed and deem malicious could just as well have been destined for Apple servers.

Apple traffic goes to 17.0.0.0/8 + CDNs aliased to .apple.com, which my egress router blocks except for Apple-documented endpoints for notifications and software update, https://support.apple.com/en-us/101555

appldnld.apple.com configuration.apple.com gdmf.apple.com gg.apple.com gs.apple.com ig.apple.com mesu.apple.com mesu.apple.com ns.itunes.apple.com oscdn.apple.com osrecovery.apple.com skl.apple.com swcdn.apple.com swdist.apple.com swdownload.apple.com swscan.apple.com updates.cdn-apple.com updates-http.cdn-apple.com xp.apple.com

There was no overlap between unexpected traffic and Apple CDN vendors.

'Apple-documented' being operative here.

True, perhaps OVH in Germany (one anomaly example) is an Apple vendor. No way to know.

They said upthread that they had blocked 17.0.0.0/8 ("Apple"), but maybe there are teams inside Apple that are somehow operating services outside of Apple's /8 in the name of Velocity? I kind of doubt it, though, because they don't seem like the kind of company that would allow for that kind of cowboying.

I don't doubt it in the slightest. Every corporate surveillance firm—I mean, third-party CDN in existence ostensibly operates in the name of 'velocity'.

Apple has used AWS and Cloudflare in the past, too, so it’s not like seeing that traffic is a reliable indicator of compromise.