Trying to confirm a network intrusion

Interestingly, the only device on this network that has ever connected to the internet is the primary security panel, so the cameras only communicate with the panel - good security architecture.

Yes, then the NVR communicates out if allowed/not locked down.  It's usually the UID settings on NVRs and cameras that should be disabled to stop this. Sometimes, the camera itself has setting to disable. I had that with my first set of cameras calling back to China even though they were disabled in the camera settings.  I called the developer out on that, and they promptly gave me firmware to access the cameras.

Regardless of them receiving information from the NVR, the cameras can also transmit.  I watch mine periodically try to do it through an entirely different IP address (a 169.254.x.x address), and I have my set up as you do - connected to the NVR via PoE (which their traffic isn't allowed out).  That doesn't mean they won't call back out.  

169.254.X.X is an APIPA IP addresses that is assigned to a device when it cannot reach a DHCP server. I didn't know that devices that were assigned this address can actually access the internet, but is assigned to devices so that they can be pinged and seen on the network.

Most of these home IP cameras do things shadily.

My IP camera attempts to connect to it's cloud service continuously non-stop. I can set the camera to point to my internal DNS server, but if the camera ever reboots it automatically resets itself back to Google's DNS 8.8.8.8.

The camera is programmed to automatically reboot every few hours if it cannot access a DNS server. It was interesting to use Wireshark to see exactly what was going on, but since I use Pihole as my DNS server I can see every single DNS lookup and add suspicious ones to the blacklist. Even if I allow the camera to reach config.amcrestcloud.com, what data it is sending is unknown, but it will do it nonstop almost every 6 seconds.

A NAT rule forces all DNS lookups to be directed to the Pihole even if devices try to bypass it.

169.254.X.X is an APIPA IP addresses that is assigned to a device when it cannot reach a DHCP server. I didn't know that devices that were assigned this address can actually access the internet, but is assigned to devices so that they can be pinged and seen on the network.

Most of these home IP cameras do things shadily.

My IP camera attempts to connect to it's cloud service continuously non-stop. I can set the camera to point to my internal DNS server, but if the camera ever reboots it automatically resets itself back to Google's DNS 8.8.8.8.

The camera is programmed to automatically reboot every few hours if it cannot access a DNS server. It was interesting to use Wireshark to see exactly what was going on, but since I use Pihole as my DNS server I can see every single DNS lookup and add suspicious ones to the blacklist. Even if I allow the camera to reach config.amcrestcloud.com, what data it is sending is unknown, but it will do it nonstop almost every 6 seconds.

A NAT rule forces all DNS lookups to be directed to the Pihole even if devices try to bypass it.

Yeah, that is the access via the NVR.  I have a Reolink NVR now, but I used to run Milestone on a server.  It's a great piece of software and I believe you can have up to 8 cameras on their free use license and uses a SQL database backend.  But you really need some CPU power to run it effectively.

At any rate, the NVRs are just as shady as the cameras, so you have to be careful with them just as much. Why they make this such a high priority for their systems to get to the internet is frankly nuts.  They preach security, but the systems themselves are so hack ridden pieces of trash, the irony is astounding.