1 Reply Latest reply on Jun 19, 2014 2:25 PM by dmease729

    ARP spoofing detected.  Query on logic used to determine 'attacker'.

    dmease729

      Hi,

       

      Came across something that stumped me for a while today.  Well, two things, but we will get to that :-)

       

      Screenshots below have been sanitised, and contain no useful information, other than to give you an idea of what we were seeing, so it may make it easier to follow.

       

      Screenshot 1: ARP reply.  PCAP downloaded directly via Threat Analyzer.  Example details (of ARP data):

          Sender MAC: 01:23:45:AB:CD:EF

          Sender IP address: 192.168.0.50

          Target MAC address: 67:89:00:AB:CD:EF

          Target IP address: 192.168.0.100

       

      Screenshot1.jpg

       

      Screenshot 2: Alert details related to PCAP.  Example details:

          Source IP address: 10.0.1.150

          Destination IP address: 192.168.0.100

       

      Screenshot2.jpg

       

      My initial thoughts: You whatty?  As ARP should be restricted to a local broadcast domain and never get routed (there may be some funky uses I am unaware of), where the eck is this 10.0.1.150 coming from?  Could it be related to proxy ARP perhaps?

       

      Next steps: While it is being investigated, filter it out so we stop getting spammed (we were getting many!).  Relevant attack filter / Exception object+assignment configured (with details from Threat Analyzer) and pushed out.  Still getting spammed.

       

      Investigation: Came across KB60821 (dated 16 Jan 2014).  Although source address is not 0.0.0.0, the logical details were interesting:

       

      "The alert filter implementation for the ARP Spoofing Detected alert is based on IP information obtained from the packet log."

      "However, IP Information displayed in the Alert Manager (AM) or Threat Analyzer (TA) is usually different from that in the packet log. The IP information displayed in the AM or TA shows the source IP as the IP address used for spoofing."

       

      Next steps: Reconfigured the exception object to reflect details in packet log.  Filter worked!  Wahey!

       

       

      So... on to the questions!

       

      1) If the original packet did not contain anything related to 10.0.1.50, where has this IP address come from?  From KB60821, this is the supposed attacker, but what is the logical process to determine this in the background?  How is this IP address being determined?*

      2) Where does 'IP protocol 21' come from??? (see screenshot 2)

       

      Cheers!

       

       

      *I suspect (although not fully sure why at the moment), that this has something to do with the local ARP cache on the sensor.  Although the 'attacking' IP looks likely to be a load balancer.  I would like to see the ARP cache myself, but from what I can see, I can only generate and upload to an encrypted zip for McAfee support.  I would love to be corrected here (I will shortly be opening another community post)!  Further investigation on the network setup is also going on in the background, but for now I want to focus on how the NSM/NSP logically gets the IP address in questio