I would say that you must not trust binaries that have been downloaded during the attack and you should check hashes now.
If they owned the ARP entry, they could have mirrored the website, and compromised binaries.

Also setting static ARP in hist host might not be a solution, as the entry must be statically set in the ISP router to be really trusted…

Regards

What ARP does is handle the IP to MAC address mappings. What would appear to have happened in this case is:

A host on the same subnet was compromised. That host was then used to send out ARP poisoning packets. The way the ARP poisoning packets work is to tell the switch that the servers are connected to that IP address w.x.y.z can be found at MAC address pp.qq.rr.ss.tt.uu.vv rather than the actual MAC address relating to that IP address. The switch then sends the packets destined for the original IP address to new MAC address and onto the compromised server which in this case, was set up to respond. Since MAC addresses are only used on the Ethernet segment and not routed across the Internet, it would have to be a host on the same Ethernet segment that was compromised.

So, Metasploit servers were not compromised in ANY way, no passwords sniffed (as far as we are aware). The DNS was not affected in any way, that’s a different type of address resolution protocol.

for a nice article on ARP poisoning:
http://www.watchguard.com/infocenter/editorial/135324.asp

most likely because they where able to compromise a host on the same ISP/ subnet and the BBC website will most likely be on another subnet/ISP. I guess the necessary requirements to use ARP poisoning on a more public target (e.g. bbc.co.uk ) weren’t met.