[Someone1234]

So how did you identify this as a breach? I'm struggling to find this credible, and you've yet to provide specifics.

Right now it comes across as "just enough knowledge to be dangerous"-levels, meaning: you've seen things, don't understand those things, and draw an unfounded conclusion.

Feel free to provide specifics, like log entry lines, that show this breach.

[walterbell]

Please feel free to ignore this sub-thread. I'm merely happy that Apple finally shipped an iPad that would last (for me! no claims about anyone else!) more than a few weeks without falling over.

To learn iOS forensics, try Corellium iPhone emulated VMs that are available to security researchers, the open-source QEMU emulation of iPhone 11 [1] where iOS behavior can be observed directly, paid training [2] on iOS forensics, or enter keywords from that course outline into web search/LLM for a crash course.

[1] https://news.ycombinator.com/item?id=44258670

[2] https://ringzer0.training/countermeasure25-apple-ios-forensi...

[saagarjha]

I worked at Corellium tracking sophisticated threats. Nothing you’ve posted is indicative of a compromise. If you’re convinced I’d be happy to go through your IOCs and try to explain them to you.

[walterbell]

Thanks. In this thread, I was trying to share a positive story about the recent iPad Pro _NOT_ exhibiting the many issues I observed over 5 years and multiple generations of iPhones and iPad Pros. If any new issues surface, I'll archive immutable logs for others to review.

[Someone1234]

I think this just further highlights my credibility point.

[walterbell]

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.

[nickburns]

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.

[walterbell]

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.

[nickburns]

'Apple-documented' being operative here.

[philsnow]

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.

[nickburns]

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

[acdha]

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