ICMP Ping Request to Broadcast Address

asked 2021-01-10 12:27:04 +0000

81 ●1 ●21 ●11

updated 2021-01-10 13:04:39 +0000

Hey,

During a client capture I saw a lot of ICMP ping requests from some Windows 10 clients (see download below). All have been sent to 255.255.255.255 with a raising TTL between 1 and 30. This scans happens every 10 minutes per client source and have a count of exactly 900 requests per scan. I can't find any common between the affected clients. They're for different usages and so they have different software installed. Our standard software like AV, backup, etc. is installed on every client. So if one of this software is the cause, I should see a lot of more clients doing this.

My guess is that this is a kind of communication. The changing TTL could be a password or paring code. My hope is that this is not a virus/trojan.

Has anybody seen this before? Any ideas how to identify the process which sends this requests?

Jas

Download capture (IP addresses sanitized by TraceWrangler)

edit retag flag offensive close merge delete

Comments

What was the original payload data? Did TraceWrangler set it to E's ?

Chuckc ( 2021-01-10 18:07:00 +0000 )edit

@Chuckc This is the original payload. TraceWrangler changed the IP addresses only.

JasMan ( 2021-01-11 06:55:18 +0000 )edit

These are all requests, is there ever an answer?

I vaguely remember something about printer drivers pulling stunts like this, does that sound familiar?

Jaap ( 2021-01-11 12:08:35 +0000 )edit

@Jaap Unfortunately the 10-minutes-pattern occured only on one client. All others are sending this requests randomly. I was not able to run a capture on a client at the right time to capture the responses. But when I use nping to send an ping to 255.255.255.255, I can't see any incoming responses on my client. I would totally aggree that printer software could do this fancy scannings. But all affeccted clients havn't any printer connected or any printer software installed.

JasMan ( 2021-01-11 13:44:09 +0000 )edit

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2021-01-11 19:56:08 +0000

Eddi

2379 ●8 ●48 ●59

Do you have a VPN client, software firewall or other tool installed, that interacts with the TCP/IP stack? I have encountered a few VPN clients in the past introduced odd behavior, like redirecting DNS queries to some unexpected server.

Another explanation would be a service that tries to collect information for some asset management or HW inventory.

Good luck Eddi

PS: In general, Windows systems won't reply to the broadcast message and some Unix systems will. I would be surprised if a router forwards the broadcast message.

edit flag offensive delete link

Comments

Hey @Eddi, Thank you. My capture from last night showed me some other ICMP packets with the same payload, but this time to an external IP address. This address belongs to our cloud-based Internet security and VPN service called "Zscaler". So you seems to be right :) I will ask the vendor support what the intention behind this scan is, and will let you know.

JasMan ( 2021-01-12 07:01:45 +0000 )edit

add a comment

answered 2021-01-11 19:24:36 +0000

Chuckc
2858 ●5 ●567 ●19

A forum post mentioning both botnets and vendor software using the "EEEE..." payload but nothing that mentions sending to the broadcast address. There are some Snort/Suricata rules that match on ICMP and the "EEEE...." payload but for very old CVEs.

It would be nice if the sysinternals tools tracked ICMP but they don't.

If it's a persistent process you may be able to identify it with a netsh trace capture, etl2pcapng and Wireshark. This only provides the process ID. If it's an ephemeral process you would need to track the running processes during the capture to get process name.
Video and slides (11: Automation TIPS & tricks Using Wireshark/tshark in Windows by Megumi Takeshita) available here: Sharkfest '20 presentations

If you can load software on the offending client machine, more detailed process information is available with the (now deprecated) Microsoft Message Analyzer (link to download it from the Internet Archive)

Some articles mention blocking outbound ICMP with a firewall loaded on the client and checking the logs for process information. I found when testing that ICMP from nmap was not blocked or logged.

edit flag offensive delete link

Comments

Hey @Chuckc, thank you for your great explanation. I appreciate your efforts! I will definitly try "netsh" and hope that the causing process is persistent.

I've also installed MS Network Analyzer on an affected client today, which is able to log the owner process of outgoing network traffic. It's currently capturing the traffic on the client an I hope, I will see the any results tomorrow. I also like your idea to block ICMP in the firewall and check the logs. I never thought about to use the logs in this way.

JasMan ( 2021-01-11 20:52:20 +0000 )edit

Good and a bad news. I was able to identify the process by blocking ICMP in the Windows Firewall, and enabling the audit logging (https://docs.microsoft.com/de-de/wind...) to see detailed informations in the security log. Unfortunately the process is "System" and the vendor of the VPN solution says, that their client don't send any ICMP packets.

JasMan ( 2021-01-17 12:42:14 +0000 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

ICMP Ping Request to Broadcast Address

Comments

2 Answers

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

ICMP Ping Request to Broadcast Address edit

Comments

2 Answers

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

ICMP Ping Request to Broadcast Address