McAfee sending traffic on UDP port 2054: is this expected behaviour?

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 (0806₁₆).

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.

I found the culprit to be McAfee's Home Network program which is part of the Anti-virus+ suite. It maps out the network you device is on identifying other network devices. It appears to probe the devices for vulnerabilities in order to protect the overall home network. I purchased the subscription with my wife's Windows 10 PC and had no idea this was one of the modules. I use a Mac and saw the udp attempt in the console last evening, appearing every minute. Your post narrowed down which service(s) to look at. I stopped the service from Windows 10 services app and viola! no more console messages. They appeared a couple of minutes after I restarted it. Wow. I now have new security app to learn! Thanks!