You can sniff the right target MAC and source IP from the traffic flowing through the port itself. (Just assume the machine itself has internet access and use

You can sniff the right target MAC and source IP from the traffic flowing through the port itself. (Just assume the machine itself has internet access and use its source IP and the target MAC it uses for public addresses.) As to the beacon itself… DNS is pretty good. Just send an innocuous DNS request to a machine you control (say a NIST time server), if you think an iterative request won't show up on radar. Or send a recursive DNS request along a path you've wiretapped. (I'd be surprised if the NSA doesn't have a feed of all DNS requests to 8.8.8.8.) Of course you will want to wait to see whether the bugged machine itself sends any such packets out first, to ensure that yours can hide in the noise. Bad idea to send a DNS beacon from a machine that doesn't ever make DNS requests. Actually on second thought, given the above capabilities, you don't even need to inject packets at all. Just mangle existing DNS queries in such a way that you can identify them in a wiretap. Say, for all DNS requests with a specific hash, mangle the ID field so that it matches some orthogonal hash (and unmangle it on the way back of course). Very unlikely to be noticed by an IPS, and you can statistically determine that machines sending more than expected packets whose ID field matches this second hash are successfully bugged. Or, why even send packets? Instead, drop all DNS request packets matching some specific hash. They'll eventually get retried with a new server or new ID. Again, statistics applied to wiretapped data can determine whom you've bugged. You don't even need store+forward capability here; just emit noise over the tail of the packet and the switch will drop it for you.