Could be an infected source code for a miner or wallet which is compiled on each platform (windows, linux etc) ...
My rigs don't have wallets running on them.
Infected source code in all sgminer, cgmniner, bfgminer, and even Cudaminer? Code I've downloaded from github and compiled myself in each case?
Seems highly unlikely. Possible, but very unlikely.
You seem to have a good sampling of configurations, so it seems like agood place to start. Do you they all run on the same local area network? If so, are they using private ip addresses with your router running network address transalation? Are they dynamically assigned or manually entered into the configuration of each mining computer?
Yes, all running on the same local network. Some are using static IP's and some dynamically assigned IP's via DHCP from the router, which is running proprietary software from the router manufacturer, though some of the rigs are bridged to the router via another router running open source dd-wrt. Quite a few different variables here. All are using Google's DNS, 8.8.8.8 and 8.8.4.4.
Many nat routers run a dns forwarding service on them. If your internet service provider assigns your public ip address via dhcp, and you assign private ip address internally via dhcp, some routers will configure the dns server for those computers to the internal ip address of the router which will forward requests onto the router's configured dns server.
If you check your ip configuration on one or more of the mining computers, does it/they point to the internal router ip address in the dns server field, or directly to an external dns server? (I ask this an many nat routers running dns forwarding service are more vulnerable to attacks than internet dns servers are.) This is a real long shot, but as it only takes a minute or to check, worth a look.
This is a good question.
Most of the rigs are configured to use 8.8.8.8 and 8.8.4.4 directly in /etc/resolv.conf. Two of them I obviously didn't change when I set them up and they are pointing to the router, which is configured to use 8.8.8.8 and 8.8.4.4.
All were affected equally.