Disclaimer: I do not work, and have not worked at McAfee (or Intel for that matter). I have not done security audits on McAfee products.
Findings and Hypothesis
What you see is ARP being send over UDP for reasons unknown. I would say the traffic is suspicious. At least, it is suspicious enough that you ask about it.
My first hypothesis was that this was some sort of VPN. Do you have a VPN? If what appears as a local network is actually working over internet, a VPN implementation that sends ARP over UDP might make sense.
Selecting the port 2054 for ARP kind of makes sense, because the EtherType for ARP is 2054 (080616).
My second hypothesis is that McAfee uses this as some form of double check for ARP, or as an attempt to fix ARP spoofing. I have found no documentation on McAfee needing UDP port 2054. Thus we can say this is not expected behavior. I wonder if this is security by obscurity, I hope it is not.
Even if the second hypothesis is correct, it could be a symptom of another problem.
My third hypothesis would be a compromised McAfee, yet, I do not know why a malware that can compromise McAfee would send this kind of traffic...
... Except, perhaps, it was done by a developer that didn't understand the difference between an EtherType and a Port (some loosely written documentation and tools refer to EtherType as Ethernet frame ports - example).
Also note there are tools that ease creating malware by allowing the malicius user to select a payload and automatically wrapping it up in the code needed for spread and infection.
My fourth and final hypothesis is that this is a bug in McAfee, which I hope they fixed in a newer version.
Investigate
- Is there software listening to UDP port 2054 on the other machines? Which software is it?
- Is McAfee on the sender machine also listening to UDP port 2054?
- Does McAfee ever get a reply? How does the reply look like?
I suggest to run Wireshark on the machine with McAfee and another machine, and capture what packets they exchange.
Under the hypothesis that this is a bug in McAfee or it has been compromised, I suggest to verify Windows and McAfee are up to date and in good integrity (sfc /scannow for Windows, executable digital signatures for McAfee - I presume they have, they better have, being from a security company).
You may also be interested in using Autoruns and Procexp from Sysinternals Suite to verify signatures and send samples to VirusTotal of software at startup (Autoruns) and in execution (Procexp). Pro tip: You can run Autoruns from the Mini Windows that comes in Hiren’s BootCD and tell it to analyze an offline system, ensuring Autoruns was not compromised by the malware.
If you believe you have a malware that has compromised the machine, consider using a rescue ISO or boot USB antimalware solution, as these would be virtually impossible to compromise for the malware.
I hope that you do not need to summon purifying fire.
Precedents
I have found another case of UDP Port 2054 on techsupportforum. In that case, apparently the solution was purifying fire reinstalling Windows.
I also found cases of problems with other ports (here, and here).
Traffic Capture Analysis
I had a look at the capture you share. This was my work process:
If you have actually captured an UDP datagram sent to the port 2054, the destination port must be the capture. 2054 in hex is 0806, and sure enough, there it is in the middle of the second line.
Therefore, we have:
/* ... data ... */
0806 Destination Port (2054)
/* ... data ... */
Now, looking at the UDP header, we have:
/* ... data ... */
/* UDP start */
d13b Source Port (53563)
0806 Destination Port (2054)
0024 Length (36 bytes)
ba22 Checksum
/* ... data ... */
I did not verify the checksum. I did verify the length (which goes from the start of the UDP header to the end) and it is correct.
This must be in an IP packet. So, let us get the IP header:
/* IP start */
4500 Version (IPv4) IHL (20 bytes) Differentiated Services (Default Forwarding)
0038 Total length (56 bytes)
16c5 Identification
0000 Flags & Fragment offset (unique fragment)
8011 TTL (128 hops) Protocol (UDP)
d2c9 Header checksum
0a14 \
1e01 -> Source IP address (10.20.30.1)
0a14 \
1efe -> Destination IP address (10.20.30.254)
/* UDP start */
d13b Source Port (53563)
0806 Destination Port (2054)
0024 Length (36 bytes)
ba22 Checksum
/* ... data ... */
We see that 10.20.30.1 is sending an UDP datagram to 10.20.30.254. Nothing fancy. Again, I checked the lenght, but not the checksum.
What about the rest of the data? This took me a bit of guessing. What protocol sends a MAC? Well, that would be ARP, but ARP does not run on top of UPD, right?
Well, ARP matches up:
/* IP start */
4500 Version (IPv4) IHL (20 bytes) Differentiated Services (Default Forwarding)
0038 Total length (56 bytes)
16c5 Identification
0000 Flags & Fragment offset (unique fragment)
8011 TTL (128 hops) Protocol (UDP)
d2c9 Header checksum
0a14 \
1e01 -> Source IP address (10.20.30.1)
0a14 \
1efe -> Destination IP address (10.20.30.254)
/* UDP start */
d13b Source Port (53563)
0806 Destination Port (2054)
0024 Length (36 bytes)
ba22 Checksum
/* ARP start */
0001 Hardware Type (Ethernet)
0800 Protocol type (IPv4)
0604 Hardware length (6 bytes, MAC) Protocol length (4 bytes, IPv4)
0001 Operation (Request)
XXXX \
XXXX -> Sender hardware address (sender's MAC address)
XXXX /
0a14 \
1e01 -> Sender protocol address (10.20.30.1)
ffff \
ffff -> Target hardware address (ignored in Operation = Request)
ffff /
0a14 \
1efe -> Target protocol address (10.20.30.254)
ARP should be running directly on top of the frame, the same way that IP runs. Instead, it is ARP running on top of UDP (which runs on top of IP).
However, if we look only at the ARP request, what is it doing? It seems to be asking 10.20.30.254 for its MAC. Except, you know, it is asking over UDP.
Which firewall network connections? The McAfee one or Windows firewall? Could you expand your answer to clarify? – Burgi – 2016-03-15T08:48:28.867
Yes, please, would like to know how to fix this issue too. – ñull – 2016-07-15T09:27:44.110