Replies

• 

  Julia Clementjuliaclement@mastodon.nz

  Oct 13, 2026, 6:45 AM

  @cdarwin If it's not there already, we can expect to find a similar facility soon in the hidden firmware (Intel Management Engine, AMD Platform Security Processor and ARM TrustZone and Secure Enclaves) The it won't matter what OS we run.

  💬 0🔄 4⭐ 18
• 

  Cassandrichdalias@hachyderm.io

  Oct 17, 2026, 12:03 PM

  @juliaclement @cdarwin Huh? In order for the identifier to matter you actually have to be sending it somewhere. Microsoft was phoning home with it. If you're not running a malicious OS and privileged software with phone home spyware in it, there is no threat here.

  💬 1🔄 0⭐ 0
• 

  Julia Clementjuliaclement@mastodon.nz

  Oct 18, 2026, 1:33 AM

  @dalias @cdarwin True. I know very little about the ARM or AMD equivalents but Intel Management Engine is another computer (CPU + Memory + non volatile storage) running a Minix derived OS that has full access to the consumer parts of the main computer.

  The main problems I saw was for a generic processor to know what sort of NIC it was dealing with, where it was mapped in the address space, the current machine address and gateway address.

  I did a little thought experiment considering Intel Management Engine as the equivalent of a hypervisor (It's probably more powerful than that). It can trap specific port addresses using the I/O Bitmap fields inside the VMCS or for memory mapped IO it can trap on permissions in the Second Level Address Translation (SLAT). This could allow it to distinguish LAN/WAN traffic and concentrate on identifying the NIC and also allow it to work out the current machine and gateway addresses. Obviously for most computers, identifying the NIC would be one-off with that information stored for future boots.

  After that it would just need to monitor the NIC for a short time after each boot to find the local IP & gateway IP and then it could potentially send an ID to a known IP address using UDP or similar.

  There's a lot of wrinkles to be sorted out, including it has to wait for the OS to be loaded and wait for it to be given an address pair for machine and gateway but I'm sure that this could be managed, my quick and dirty approach would be to wait 5 minutes after power-up and leave the guest OS to do the heavy lifting. Give me a few million Euros plus tech specs of the Intel Management Engine and I'll have a better plan to share.

  💬 1🔄 0⭐ 0
• 

  Cassandrichdalias@hachyderm.io

  Oct 18, 2026, 1:49 AM

  @juliaclement @cdarwin That's a lot of work but plausible. But it still doesn't tie a machine identity to particular activity interacting with particular sites. All of those connections are going to be TLS with endpoint on what's effectively a guest under the malicious Intel negative-ring hypervisor. So it would have to deeply interfere with execution to modify data in transit, in cooperation with particular sites while simultaneously remaining unknown to public, or else steal session keys from the guest to use for identifying sessions.

  Keep in mind that where this attack was useful was when the victim was behind a VPN, so just matching the hardware identifier to the ethernet/wifi adapter's IP is not useful. The attacker needs to match it to the VPN exit IP that the sites you're connecting to see.

  💬 1🔄 0⭐ 0
• 

  Julia Clementjuliaclement@mastodon.nz

  Oct 18, 2026, 3:26 AM

  @dalias @cdarwin The machine ID can be set during factory initialisation.
  For non-vpn traffic. It seems that the recently accessed IP addresses are stored in the NIC as "Protocol ARP Offload (along with NS Offload for IPv6). It is standard on modern Intel laptop Network Interface Cards (NICs), including wireless modules like the Intel Wi-Fi 6E AX211 and wired controllers like the Intel Ethernet Connection I219-V." [Google search results] and (If I've interpreted what I read from other searches correctly) can be retrieved from the NIC or from the Miniport driver (or its Linux equivalent).
  Periodically the (for want of a better name) NSATrack module can send a list of recently accessed IP addresses.

  For VPNs, it would probably need to be something more intrusive on the client OS, but Conntrack / Netfilter logs, DNS Caches / Browser History and VPN Client Logs are all good places to start. Again the NSATrack packets can be sent either over the VPN to give the apparent source IP or directly through the local NIC to avoid Track(dot)NSA(dot)GOV showing in the local VPN logs.

  I'm pretty sure it can be done, but the price is likely to be a lot more than I suggested. Quietly live patching multiple operating systems seems like something a government could achieve but I'd rather not touch.

  💬 0🔄 0⭐ 0