[g_p]

I don't believe there are proper application level firewalls. You can however (at least if the entire OS isn't compromised at the time of the network requests) get something which is better than nothing through the private DNS API.

If you configure your own private DNS server over DNS-over-HTTPS, and have your own logging on it, you can review your DNS logs across any devices configured to use it, rapidly.

While keeping a log of your own DNS queries might be a risk for some threat models, if you aren't doing this, chances are you were sending your DNS traffic in the clear to your ISP or mobile operator (or into a VPN provider of questionable trust). You probably aren't a huge amount more exposed by logging it for yourself.

This let me check for any of the IOC domains given in the write-up. While no doubt there will be attacks which could override the provisioning profile that forces this DNS to be used, it would still need to get into the system without making a query that's part of the IOCs. That limits attack vectors a fair bit - the payloads here seemed to do a fair bit of network-based fetching of subsequent payloads. The hostnames of these requests should be logged on your DNS and enable you to rapidly confirm if exposed.

As a bonus you can do host level ad blocking via this DNS server, which should definitely be the minimum you do if you're concerned about skilled attacker threat models - code execution in the browser via a delivered ad isn't something you want to make easy!

[ignoramous]

> If you configure your own private DNS server over DNS-over-HTTPS, and have your own logging on it, you can review your DNS logs across any devices configured to use it, rapidly.

Pegasus can always DoH its DNS queries to a server of its choosing bypassing any and all network-wide / os-wide DNS settings. Granted IoCs can be set to flag such behaviour. Besides, DNS and ICMP can be additionally be used to siphon off data too.

When used carefully, IP firewalls make for a good defence.

> ...if you're concerned about skilled attacker threat models - code execution in the browser via a delivered ad isn't something you want to make easy!

True. If NSO group is in your threat-model, it definitely warrants extreme paranoia and caution.

[g_p]

Good point - perhaps didn't make the limitations clear enough though - this would only help if the early payload gets delivered through a request made to a remote server (which inherently goes through default system DNS).

That's a fairly common compromise model though in my view - a message might contain a URL, and your phone might locally do a fetch of it to prepare a pretty preview, and that might try to exploit some weakness in the browser engine or whatever.

Given this was delivered via iMessage you're right - once they have code execution, the attacker can evade your DNS. If they can't get enough code in through their initial method to get their own DNS going, they might send a dropper which then pulls more code in from elsewhere, and that may give you an IOC to detect from that first query. If they can front their content on a popular domain though, this won't help.

Definitely favour network level protections before doing this, but if you just want the ability to get a view of your own DNS traffic from your device when it moves across WiFi and mobile data, this will give you a starting point.