I know just enough about networking to be dangerous. This is a story of some network activity that I find strange. I can't fully explain what I saw, so, hopefully, someone more expert in the topic can. If so, this will be updated with the explanation.

The story starts with my router, which is configured to not allow Windows file sharing over the Internet. I do lots of file sharing on my LAN and that's the only place it belongs.

Most people can not do this. Consumer routers and the cheap junky ones supplied by ISPs do not offer configurable firewall rules. I use the $200 Pepwave Surf SOHO, a low end business class router.

To block file sharing on the Internet, I have configured these outbound firewall rules:

1. Anything to UDP ports 137 and 138 is blocked and logged
2. Anything to TCP ports 139 and 445 is blocked and logged

These rules were in place for a long time and nothing was ever logged. Until recently, when I saw a ton of traffic blocked from a Windows 10 computer. Specifically, I was seeing attempted outbound connections to UDP port 137. The classic use for UDP port 137 is the Windows Netbios name service. That said, any pair of computers can send any data they want over UDP port 137. A bit of searching turned up some other uses for this port. So, no assumptions can be made.

Eventually, I found the source of these outbound connections - the Brave browser. Specifically, Brave version 0.66.99 (Chrome 75.0.3770.100) Official Build 64 bit.

In my testing, I would start the browser, which opened to a blank page and leave it there. The strange network traffic is from the browser itself and not a web page.

I have seen this behavior on two different Windows 10 computers. I have not tested Brave on any other system. It also runs on macOS, iOS and Android.

Here is an edited excerpt of what my router logged:

18:21:13 Denied SRC=192.168.3.224 DST=104.28.22.242 PROTO=UDP SPT=137 DPT=137
18:21:11 Denied SRC=192.168.3.224 DST=104.28.22.242 PROTO=UDP SPT=137 DPT=137
18:21:10 Denied SRC=192.168.3.224 DST=104.28.22.242 PROTO=UDP SPT=137 DPT=137
18:19:33 Denied SRC=192.168.3.224 DST=151.101.21.7  PROTO=UDP SPT=137 DPT=137
18:19:33 Denied SRC=192.168.3.224 DST=151.101.21.7  PROTO=UDP SPT=137 DPT=137
18:19:33 Denied SRC=192.168.3.224 DST=151.101.65.7  PROTO=UDP SPT=137 DPT=137
18:19:31 Denied SRC=192.168.3.224 DST=151.101.21.7  PROTO=UDP SPT=137 DPT=137
18:19:31 Denied SRC=192.168.3.224 DST=151.101.21.7  PROTO=UDP SPT=137 DPT=137
18:19:31 Denied SRC=192.168.3.224 DST=151.101.65.7  PROTO=UDP SPT=137 DPT=137
18:19:30 Denied SRC=192.168.3.224 DST=151.101.21.7  PROTO=UDP SPT=137 DPT=137
18:19:30 Denied SRC=192.168.3.224 DST=151.101.21.7  PROTO=UDP SPT=137 DPT=137
18:19:30 Denied SRC=192.168.3.224 DST=151.101.65.7  PROTO=UDP SPT=137 DPT=137
18:16:21 Denied SRC=192.168.3.224 DST=151.101.21.7  PROTO=UDP SPT=137 DPT=137
18:16:20 Denied SRC=192.168.3.224 DST=151.101.21.7  PROTO=UDP SPT=137 DPT=137
18:16:18 Denied SRC=192.168.3.224 DST=151.101.21.7  PROTO=UDP SPT=137 DPT=137

SRC is the source IP address, DST is the destination IP address, PROTO is the protocol, SPT is the source port and DPT is the destination port. As the timestamps show, the browser is persistent, it tries repeatedly to make contact. For networking experts, more detailed log entries are here.

The IP addresses that I have seen Brave trying to communicate with on UDP port 137 are:

104.28.22.242 104.244.42.72 151.101.21.7 151.101.65.7 151.101.66.2 151.101.129.7 72.21.91.29 72.21.91.66

It occurred to me that I had downloaded a hacked version of the browser, so I uploaded the EXE file to Virus Total, where it got a clean bill of health.

So, if this outgoing traffic was by design, then the computers at these IP addresses should have UDP port 137 open. Do they? Hard to say.

I tested each of these IP addresses using this nmap command: nmap -sU -p 137 targetipaddress. I also tested them using the port scanner at ipfingerprints.com. Every test was inconclusive. The status of UDP port 137 was always "open|filtered" which means that Nmap is unable to determine whether a port is open or filtered. If Brave is phoning home to spy on people, then a receive-only UDP port would be the perfect way to go.

What to make of these IP addresses? In one respect they look legitimate, but looked at another way, they are suspicious.

Looking at the DNS queries made on the PC, they look normal enough. I started Nir Sofer's DNSQuerySniffer and then ran the browser. All DNS queries were sent to OpenDNS. As shown below, there were no queries to anything but sub-domains of brave.com.

104.28.22.242	static.brave.com
151.101.21.7	go-updater.brave.com safebrowsing.brave.com componentupdater.brave.com
151.101.65.7	laptop-updates.brave.com
151.101.129.7	laptop-updates.brave.com

If this was a spy operation, then one or more of these sub-domains was created at the request of the spy agency. Too much James Bond? Then keep in mind, these are only computers that Brave tried to contact on UDP port 137. At the same time it was using TCP and port 443 for lots of other communication. Strange.

Next, I looked at Shodan to see what it knew about the computers at some of these IP addresses. the nice thing about Shodan is that on ports supporting TLS (usually 443) it dumps out the details of the certificate. This identifies the computer using both a Canonical Name (CN) and alternate names (Subject Alternative Names). Alternate names is what allows multiple independent websites to exist on the same server computer.

The computer at 104.28.22.242 (static.brave.com) belongs to Cloudflare and has many open ports (80, 443, 2082, 2086, 2087, 8080, 8880) and many known vulnerabilities. The first time I checked Shodan, there was no valid certificate at port 443 to identify the server. However, the next day there was. The CN of the server is sni36298.cloudflaressl.com and the list of Subject Alternative Names is shown below:

DNS:sni36298.cloudflaressl.com, DNS:*.15dressesmintshop.ml, DNS:*.azmobtds.com, DNS:*.batcommunity.org, DNS:*.brave.com, DNS:*.bymeld.gq, DNS:*.companyman.us, DNS:*.cyberxzt.net, DNS:*.doubletakecreations.biz, DNS:*.drippoh.ga, DNS:*.eyewearquiz.science, DNS:*.finirenkk.gq, DNS:*.forfamilies.com, DNS:*.gxhrp.gq, DNS:*.irasam.cf, DNS:*.maimbjr.gq, DNS:*.music-top-mix.pw, DNS:*.newmovies-life.pw, DNS:*.newvideos.pw, DNS:*.onedeals.eu, DNS:*.qnpuyu.gq, DNS:*.readtwlct.cf, DNS:*.regul8approval.co.uk, DNS:*.sarahjonescreative.co, DNS:*.sbk530.com, DNS:*.sbk844.com, DNS:*.ssk013.com, DNS:*.ssk018.com, DNS:*.ssk020.com, DNS:*.ssk023.com, DNS:*.sspk02.com, DNS:*.standingdoggyshop.ml, DNS:*.uaermobtds.com, DNS:15dressesmintshop.ml, DNS:azmobtds.com, DNS:batcommunity.org, DNS:brave.com, DNS:bymeld.gq, DNS:companyman.us, DNS:cyberxzt.net, DNS:doubletakecreations.biz, DNS:drippoh.ga, DNS:eyewearquiz.science, DNS:finirenkk.gq, DNS:forfamilies.com, DNS:gxhrp.gq, DNS:irasam.cf, DNS:maimbjr.gq, DNS:music-top-mix.pw, DNS:newmovies-life.pw, DNS:newvideos.pw, DNS:onedeals.eu, DNS:qnpuyu.gq, DNS:readtwlct.cf, DNS:regul8approval.co.uk, DNS:sarahjonescreative.co, DNS:sbk530.com, DNS:sbk844.com, DNS:ssk013.com, DNS:ssk018.com, DNS:ssk020.com, DNS:ssk023.com, DNS:sspk02.com, DNS:standingdoggyshop.ml, DNS:uaermobtds.com

Virus Total also found multiple URLs under this IP address.

The computer at 104.244.42.72 appears to be a Twitter web server. I say web server because Shodan reports that ports 80 (HTTP) and 443 (HTTPS) are the only open ports. The certificate on port 443 identifies the machine as syndication.twitter.com (from the CN). The Subject Alternate names in the certificate are: syndication.twitter.com, cdn.syndication.twitter.com, syndication-o.twitter.com, syndication.twimg.com, cdn.syndication.twimg.com and syndication-o.twimg.com. It's Twitter.

The computer at 151.101.21.7 (go-updater.brave.com and safebrowsing.brave.com and componentupdater.brave.com) also appears to be a web server. The CN in the certificate identifies it as p.ssl.fastly.net and the list of Subject Alternative Names is shown below:

DNS:p.ssl.fastly.net, DNS:*.brave.com, DNS:*.cmcdn.net, DNS:*.corebine.com, DNS:*.corednacdn.com, DNS:*.experiencepoint.com, DNS:*.foxtons.co.uk, DNS:*.freitag.ch, DNS:*.fs.pastbook.com, DNS:*.gadventures.ch, DNS:*.gadventures.de, DNS:*.ggcircuit.com, DNS:*.i.thechive.com, DNS:*.knect365.com, DNS:*.lulus.com, DNS:*.mediavine.com, DNS:*.mos.org, DNS:*.netzwelt.de, DNS:*.onceit.co.nz, DNS:*.racingpost.com, DNS:*.shave.io, DNS:*.sonar.digitalocean.com, DNS:*.unsplash.com, DNS:*.velpic.com, DNS:*.vidyard.com, DNS:1stdibs.com, DNS:ad.tagdelivery.com, DNS:amp.cnn.com, DNS:api.pdflayer.com, DNS:app.hiresuccess.com, DNS:bestpractices.coreinfrastructure.org, DNS:brave.com, DNS:bundler.io, DNS:corebine.com, DNS:data.ripple.com, DNS:eightiesyourself.cnn.com, DNS:ggcircuit.com, DNS:hypebeast.com, DNS:knect365.com, DNS:makefastlywork.solutionsbywaters.com, DNS:master.bestpractices.coreinfrastructure.org, DNS:mediavine.com, DNS:mos.org, DNS:onceit.co.nz, DNS:seoghoer-fastly-production.shape.dk, DNS:staging.bestpractices.coreinfrastructure.org, DNS:staging.lightingdirect.com, DNS:static.dyn.com, DNS:static.parastorage.com, DNS:unsplash.com, DNS:widget.perfectmarket.com, DNS:www.bundler.io, DNS:www.jurists.co.jp, DNS:www.msgsafe.io, DNS:www.onceit.com.au, DNS:www.pinalove.com, DNS:www.thaifriendly.com, DNS:www.wada-ama.org, DNS:zensaskincare.com

Finally, the computer at 72.21.91.29 is a web server belonging to Digicert. The CN in the certificate identifies it as www.digicert.com and the Subject Alternative Names are all sub-domains of digicert.com.

So, why is Brave opening a connection on UDP port 137 to these very different computers?

Brave has an online forum and I will open a question there, but the last time I did so, my question was ignored.

Anyone know what's going on?

More Information Part 1

A helpful Twitter user sent me a relevant link. Back in 2002, someone running Windows XP asked why browsing websites caused his PC to send UDP packets on port 137 to some (not all) of the websites he was browsing.

One response was that Windows XP broadcasts to every computer it finds on the network, be it another computer on the local network, or a web server on the Internet. This person said their corporate firewall was flooded with denied outbound SMB traffic. But, that does not explain why it only happens to some websites. And, in my case, the rule blocking UDP port 137 was had been in place for quite a while and I just started noticing the router actually blocking things.

Another response was that Windows XP was trying to resolve the remote host via NetBIOS name as well as with DNS. This person claimed that if you do a trace router to any web server, you will see that each hop tries to resolve via NetBIOS along with DNS. I tested this and found it mostly false. I ran a tracert command and found no outgoing UDP port 137 traffic on a Windows 7 PC, on another Windows 10 PC and on the same PC where I had been testing Brave. But ... on the Windows 7 PC when a VPN was active, the router blocked three outgoing UDP requests on port 137 to IP address 10.15.0.1 which is on the internal LAN of the VPN provider. I'm not sure which firewall rule triggered this as the router also blocks outbound traffic to any IP address starting with 10.

More Information Part 2

Before I narrowed down the issue to the Brave browser, the router had also blocked outbound UDP port 137 to the IP addresses described below. All the port 137 traffic was from a second Windows 10 computer, not the one described above. At the time the machine was running multiple web browsers and looking at multiple websites. Why the PC only tried to communicate with some computers on UDP port 137, I don't know. Shown below are those that it tried to contact.

IP address 104.16.208.165 is hosted at Cloudflare and it has many open ports (80, 443, 2052, 2082, 2083, 2086, 2087, 2095, 8080, 8443, 8880). The CN is ssl473492.cloudflaressl.com the alternate names are ssl473492.cloudflaressl.com, *.onesignal.com, onesignal.com. IP address 104.16.207.165 is the same.

IP address 104.18.25.243 as has many open ports. The CN is sni.cloudflaressl.com and the alternate names are leidenschaftnatur.de and sni.cloudflaressl.com.

IP address 40.126.2.38 is a Microsoft Azure web server with many alternate names, shown below, all belonging to Microsoft.

DNS:*.accesscontrol.windows.net, DNS:*.accesscontrol.windows-ppe.net, DNS:*.b2clogin.com, DNS:*.cpim.windows.net, DNS:*.microsoftaik.azure.net, DNS:*.microsoftaik-int.azure-int.net, DNS:*.windows-ppe.net, DNS:aadg.windows.net, DNS:aadgv6.ppe.windows.net, DNS:aadgv6.windows.net, DNS:account.live.com, DNS:account.live-int.com, DNS:api.password.ccsctp.com, DNS:api.passwordreset.microsoftonline.com, DNS:autologon.microsoftazuread-sso.com, DNS:becws.ccsctp.com, DNS:clientconfig.microsoftonline-p.net, DNS:clientconfig.microsoftonline-p-int.net, DNS:companymanager.ccsctp.com, DNS:companymanager.microsoftonline.com, DNS:cpim.windows.net, DNS:device.login.microsoftonline.com, DNS:device.login.windows-ppe.net, DNS:directoryproxy.ppe.windows.net, DNS:directoryproxy.windows.net, DNS:graph.ppe.windows.net, DNS:graph.windows.net, DNS:graphstore.windows.net, DNS:login.live.com, DNS:login.live-int.com, DNS:login.microsoft.com, DNS:login.microsoftonline.com, DNS:login.microsoftonline-p.com, DNS:login.microsoftonline-pst.com, DNS:login.microsoft-ppe.com, DNS:login.windows.net, DNS:logincert.microsoftonline.com, DNS:logincert.microsoftonline-int.com, DNS:login-us.microsoftonline.com, DNS:microsoftaik.azure.net, DNS:microsoftaik-int.azure-int.net, DNS:nexus.microsoftonline-p.com, DNS:nexus.microsoftonline-p-int.com, DNS:pas.windows.net, DNS:pas.windows-ppe.net, DNS:password.ccsctp.com, DNS:passwordreset.activedirectory.windowsazure.us, DNS:passwordreset.microsoftonline.com, DNS:provisioning.microsoftonline.com, DNS:signup.live.com, DNS:signup.live-int.com, DNS:sts.windows.net, DNS:xml.login.live.com, DNS:xml.login.live-int.com, DNS:*.login.microsoftonline.com, DNS:login.microsoftonline-int.com, DNS:accesscontrol.aadtst3.windows-int.net, DNS:*.accesscontrol.aadtst3.windows-int.net, DNS:api.login.microsoftonline.com

IP address 13.107.21.200 is also an Azure web server with a CN of www.bing.com and the many Microsoft alternate names shown below.

DNS:www.bing.com, DNS:dict.bing.com.cn, DNS:*.platform.bing.com, DNS:*.bing.com, DNS:bing.com, DNS:ieonline.microsoft.com, DNS:*.windowssearch.com, DNS:cn.ieonline.microsoft.com, DNS:*.origin.bing.com, DNS:*.mm.bing.net, DNS:*.api.bing.com, DNS:ecn.dev.virtualearth.net, DNS:*.cn.bing.net, DNS:*.cn.bing.com, DNS:ssl-api.bing.com, DNS:ssl-api.bing.net, DNS:*.api.bing.net, DNS:*.bingapis.com, DNS:bingsandbox.com, DNS:feedback.microsoft.com, DNS:insertmedia.bing.office.net, DNS:r.bat.bing.com, DNS:*.r.bat.bing.com, DNS:*.dict.bing.com.cn, DNS:*.dict.bing.com, DNS:*.ssl.bing.com, DNS:*.appex.bing.com, DNS:*.platform.cn.bing.com, DNS:wp.m.bing.com, DNS:*.m.bing.com, DNS:global.bing.com, DNS:windowssearch.com, DNS:search.msn.com, DNS:*.bingsandbox.com, DNS:*.api.tiles.ditu.live.com, DNS:*.ditu.live.com, DNS:*.t0.tiles.ditu.live.com, DNS:*.t1.tiles.ditu.live.com, DNS:*.t2.tiles.ditu.live.com, DNS:*.t3.tiles.ditu.live.com, DNS:*.tiles.ditu.live.com, DNS:3d.live.com, DNS:api.search.live.com, DNS:beta.search.live.com, DNS:cnweb.search.live.com, DNS:dev.live.com, DNS:ditu.live.com, DNS:farecast.live.com, DNS:image.live.com, DNS:images.live.com, DNS:local.live.com.au, DNS:localsearch.live.com, DNS:ls4d.search.live.com, DNS:mail.live.com, DNS:mapindia.live.com, DNS:local.live.com, DNS:maps.live.com, DNS:maps.live.com.au, DNS:mindia.live.com, DNS:news.live.com, DNS:origin.cnweb.search.live.com, DNS:preview.local.live.com, DNS:search.live.com, DNS:test.maps.live.com, DNS:video.live.com, DNS:videos.live.com, DNS:virtualearth.live.com, DNS:wap.live.com, DNS:webmaster.live.com, DNS:webmasters.live.com, DNS:www.local.live.com.au, DNS:www.maps.live.com.au

The IP address 151.139.128.14 is a web server belonging to the Highwinds Network Group. It has a CN of *.ssl.hwcdn.net and an alternate name of ssl.hwcdn.net.

The IP address 74.119.119.131 is a web server belonging to Criteo Corp. It has a CN of *.criteo.com and an alternate name of criteo.com.

The IP address 45.60.11.212 belongs to Incapsula and has an amazing 40 open ports. The CN is incapsula.com and the alternate names are *.chiltepin.net, *.services.spiceworks.com, *.spiceworks.com, *.spiceworksstatic.com and spiceworks.com.

The IP address 52.230.222.68 is strange. It is hosted at Microsoft Azure and 443 is the only open port. But, there is no certificate at port 443. Censys.io says that the CN is *.wns.windows.com.

More Information Part 3

I opened a Brave Community post about this on July 16, 2019.

Next, I realized that the computer had the Malwarebytes (formerly Binisoft) Windows Firewall installed and hoped its logging feature might turn up an interesting pattern. It did.

The most striking thing the log showed was the the requests did not come directly from the Brave browser or from the Brave updater program, they were made by Windows system process number 4, which is identified only as "System" The screen shot below shows four network events that happened in the same second. The oldest event is on the bottom.

First, the Brave Software Updater phones home on TCP port 443 to 151.101.130.2. This IP address has a dozens of alternate names, two of which are updates.bravesoftware.com and updates-cdn.bravesoftware.com. Then, Windows makes a couple DNS requests (UDP port 53 to 1.1.1.1). Then, the good part, Windows process number 4 makes an outgoing request on UDP port 137 to the same IP address. Is Windows doing this on its own, or is it just responding to a request from the Brave Software Updater?

Could it be that the port 137 traffic is due to the updater program rather than the browser itself? No, as we see in the log excertp below.

Here, we have clearly caught the browser in the act of generating traffic to UDP port 137. First, it makes a TCP request on port 443 to 104.28.22.242 which a DNS log showed to be static.brave.com. Immediately thereafter, Windows System process number 4 makes a request to the same IP address on UDP port 137. Then, another browser request on TCP port 443 to the same IP address.

The network log is sortable, so I sorted it by destination port number to see all the requests to port 137. As shown below, they all use UDP, none are TCP. And, they all come from Process number 4, none came directly from Brave (though the system could simply be doing what Brave requested as we saw above with the DNS requests.

Many of the requests were meant for the LAN. For example, IP address 10.44.44.255 is a broadcast address for the subnet (10.44.44.x) that the computer was on.

Another LAN side request is worrying, but off-topic. The computer is a laptop that was using Wi-Fi at the time. When it uses Ethernet, it lives on the 192.168.1.x subnet and 192.168.1.66 is a device that shares files on that network. Why Windows 10 is trying to get at shared files for a subnet that it is not connected to is, well, typical of Microsoft.

As for the Internet, we see requests to 151.101.21.7, 151.101.129.7, 151.101.130.217, 151.101.130.2 and 104.28.22.242.

As noted above, the first IP address (151.101.21.7) is known by at least three Brave related names, go-updater.brave.com, safebrowsing.brave.com and componentupdater.brave.com, but it also answers to a couple dozen other names having nothing to do with Brave.

The second one (151.101.129.7) is laptop-updates.brave.com, though Shodan reports that it too has a couple dozen other names as well.

The third one (151.101.130.217) is is a web server with 121 different names, none of which has anything to do with Brave. An outlier.

The fourth one (151.101.130.2) we have seen used by the Brave Software Updater which also contacted it on TCP port 443. Among its many alternate names are updates.bravesoftware.com and updates-cdn.bravesoftware.com.

The last one (104.28.22.242) we have also seen before as static.brave.com but it has a couple dozen non-Brave alternate names.

What is Windows system process number 4? Much of it is blocked from inspection by Process Explorer. From what I can gather it hosts many drivers and services, and thus is a dead end.

Since all the UDP 137 requests come from Windows, it is possible that this is a Windows thing, not a Brave thing. However, I cold booted the PC in question, opened Firefox, went a half dozen websites and let it sit for a while. There were no Internet requests out to UDP port 137. So, it's a Brave issue.

July 17, 2019: The behavior is not consistent. Today, I tried to re-create it with Wireshark running on the PC and I could not. There were no connections to any Internet IP address on UDP port 137, just the normal LAN side traffic on that port.

More Information Part 4 -Windows 7

Wondering if this was a Windows 10 thing only, I installed the Brave browser on a Windows 7 computer. After some initial configuration, I started a trace on the computer, then started the browser which opened to the New Tab pgae and waited ... but there was no outbound traffic to UDP port 137.

Then, I checked the router. There had been a lot of such traffic, either during the installation or perhaps the first time the browser ran. I wasn't watching the clock that carefully. And, the computer was not doing anything else at the time. As the log excerpt below shows, the computer tried to contact these computers on port 137: 173.194.61.9 (Google) 13.225.212.117 (unknown) 13.225.212.79 (sodrelcareers.com) 13.225.202.56 (cdn.mozilla.net) 151.101.192.133 (Github.com) 151.101.22.133 (d.sni.fastly.net) 151.139.128.14 (ssl.hwcdn.net) 72.21.81.240 (Microsoft) 72.21.91.66 (Twitter) 72.21.91.70 (Twitter) 192.229.173.16 (Twitter) 104.244.42.72 (Twitter)

Nothing to do with Brave at all.

11:42:26 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=173.194.61.9
11:42:26 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=13.225.212.79
11:42:25 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=173.194.61.9
11:42:25 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=13.225.212.79
11:42:23 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=173.194.61.9
11:42:23 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=13.225.212.79
11:42:15 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=13.225.212.117
11:42:14 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=13.225.212.117
11:42:12 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=13.225.212.117
11:42:11 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=151.101.192.133
11:42:10 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=151.101.192.133
11:42:08 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=151.101.192.133
11:41:20 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=151.139.128.14
11:41:20 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=72.21.81.240
11:41:19 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=72.21.81.240
11:41:19 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=151.139.128.14
11:41:17 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=151.139.128.14
11:41:17 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=72.21.81.240
11:41:16 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=72.21.91.66
11:41:14 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=72.21.91.66
11:41:13 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=72.21.91.66
11:41:12 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=192.229.173.16
11:41:11 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=192.229.173.16
11:41:11 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=104.244.42.72
11:41:11 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=72.21.91.70
11:41:10 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=72.21.91.66
11:41:10 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=192.229.173.16
11:41:10 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=72.21.91.66
11:41:10 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=192.229.173.16
11:41:09 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=104.244.42.72
11:41:09 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=72.21.91.70
11:41:09 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=72.21.91.66
15:41:09 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=192.229.173.16
11:41:09 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=72.21.91.66
11:41:08 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=192.229.173.16
11:41:08 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=104.244.42.72
11:41:08 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=72.21.91.70
11:41:07 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=72.21.91.66
11:41:07 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=72.21.91.66
11:40:30 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=13.225.212.79
11:40:29 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=13.225.212.79
11:40:27 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=13.225.212.79
11:40:20 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=151.139.128.14
11:40:20 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=151.139.128.14
11:40:20 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=72.21.81.240
11:40:19 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=151.139.128.14
11:40:18 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=151.139.128.14
11:40:18 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=72.21.81.240
11:40:17 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=151.139.128.14
11:40:17 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=151.139.128.14
11:40:17 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=72.21.81.240
11:40:15 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=151.101.192.133
11:40:13 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=151.101.192.133
11:40:12 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=151.101.192.133
11:39:48 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=151.101.22.133
11:39:46 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=151.101.22.133
11:39:45 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=151.101.22.133
11:39:25 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=151.101.22.133
11:39:23 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=151.101.22.133
11:39:22 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=151.101.22.133
11:39:04 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=13.225.202.56
11:39:02 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=13.225.202.56
11:39:01 SRC=192.168.5.188 PROTO=UDP SPT=137 DPT=137 DST=13.225.202.56

Still a mystery.

- - - - - - - - - - - -

July 19, 2019: Now, that I have finally moved on to Wireshark to log the data being sent to UDP port 137, I can not generate any more such traffic. Brave, running on the original Windows 10 computer, sat open all day yesterday and the computer did not make one WAN request to UDP port 137. Bah, humbug.

- - - - - - - - - - - -

July 29, 2019: No more occurrences of UDP port 137 traffic. But, I did get a response from Brave to my question on their forum:

So what you are seeing is nothing unusual. Brave installs components which are downloaded as the browser is opened. For example, Tracking protection/HTTPSE ruleset/ Safe browsing ruleset etc are downloaded/checked for updates when the browser is launched. All these go via Brave proxy which you have listed on your page. Also, every time the browser is launched a background update process is also launched automatically which you have also captured in your report. If you have sync enabled in your browser then there will be frequent calls to the sync server to check for updates which is also normal and will show up in your network scan. If you have rewards enabled, then each launch will trigger a download for verified publishers list which will also create a connection. As long as you have downloaded via brave.com/download and installed all these are normal connections that happen which are not strange connections. You can visit brave://components and see all Brave components that get downloaded.

No mention about UDP port 137. Strange that.

Not Just Brave

July 3, 2020. This happened again on fairly new Windows 10 computer that did not have the Brave browser installed. It did, however, have Chrome installed and Brave is based on Chrome. As before, both the source port and the destination port are 137. And, all requests are UDP.

15:50:58 SRC=192.168.5.45 DST=104.44.36.91   ID=18397 PROTO=UDP SPT=137 DPT=137
15:50:57 SRC=192.168.5.45 DST=104.44.36.91   ID=18396 PROTO=UDP SPT=137 DPT=137
15:50:55 SRC=192.168.5.45 DST=104.44.36.91   ID=18395 PROTO=UDP SPT=137 DPT=137
15:50:53 SRC=192.168.5.45 DST=66.109.5.119   ID=12294 PROTO=UDP SPT=137 DPT=137
15:50:51 SRC=192.168.5.45 DST=66.109.5.119   ID=12293 PROTO=UDP SPT=137 DPT=137
15:50:50 SRC=192.168.5.45 DST=66.109.5.119   ID=12292 PROTO=UDP SPT=137 DPT=137
15:50:43 SRC=192.168.5.45 DST=52.114.159.112 ID=12100 PROTO=UDP SPT=137 DPT=137
15:50:41 SRC=192.168.5.45 DST=52.114.159.112 ID=12099 PROTO=UDP SPT=137 DPT=137
15:50:40 SRC=192.168.5.45 DST=52.114.159.112 ID=12098 PROTO=UDP SPT=137 DPT=137

According to ipinfo.io, the first IP address (104.44.36.91) belongs to Microsoft and the second one (66.109.5.119) belongs to Charter Spectrum. The third one (52.114.159.112) also belongs to Microsoft and Shodan says that it is hosting many Microsoft sites, including *.events.data.microsoft.com.

Yet Again

July 7, 2020. It happened again today on two different Windows 10 machines. One was the same PC as 4 days ago, it does not have the Brave browser installed. As before, both the source port and the destination port are 137. And, all requests are UDP and there are clumps of 3 requests at a time. In the log excerpt below, I have left out the redundant data. I was using both computers but did not see the error until hours later, so not sure what I was doing at the time.

One new thing here is the attempt to contact an internal-use-only IP address 10.129.0.1. And, almost all the destination IP addresses belong to Google.

11:42:37 SRC=192.168.5.46 DST=172.253.76.133 (google)
11:42:36 SRC=192.168.5.46 DST=172.253.76.133
11:42:34 SRC=192.168.5.46 DST=172.253.76.133
11:42:20 SRC=192.168.5.46 DST=216.239.46.64 (google)
11:42:18 SRC=192.168.5.46 DST=216.239.46.64
11:42:17 SRC=192.168.5.46 DST=216.239.46.64
11:42:03 SRC=192.168.5.46 DST=66.249.95.219 (google)
11:42:01 SRC=192.168.5.46 DST=66.249.95.219
11:42:00 SRC=192.168.5.46 DST=66.249.95.219
11:41:45 SRC=192.168.5.46 DST=108.170.236.128 (google)
11:41:44 SRC=192.168.5.46 DST=108.170.236.128
11:41:42 SRC=192.168.5.46 DST=108.170.236.128
11:41:28 SRC=192.168.5.46 DST=108.170.249.44
11:41:26 SRC=192.168.5.46 DST=108.170.249.44
11:41:25 SRC=192.168.5.46 DST=108.170.249.44
11:41:11 SRC=192.168.5.46 DST=209.85.173.168 (google)
11:41:09 SRC=192.168.5.46 DST=209.85.173.168
11:41:08 SRC=192.168.5.46 DST=209.85.173.168

11:40:27 SRC=192.168.5.46 DST=10.129.0.1 (internal only)
11:40:26 SRC=192.168.5.46 DST=10.129.0.1
11:40:24 SRC=192.168.5.46 DST=10.129.0.1

11:40:05 SRC=192.168.5.45 DST=74.125.147.198 (google)
11:40:03 SRC=192.168.5.45 DST=74.125.147.198
11:40:02 SRC=192.168.5.45 DST=74.125.147.198
11:39:59 SRC=192.168.5.45 DST=66.109.5.138 (Spectrum, same subnet as 4 days ago)
11:39:58 SRC=192.168.5.45 DST=66.109.5.138
11:39:56 SRC=192.168.5.45 DST=66.109.5.138
11:36:10 SRC=192.168.5.45 DST=74.125.147.198 (google)
11:36:08 SRC=192.168.5.45 DST=74.125.147.198
11:36:07 SRC=192.168.5.45 DST=74.125.147.198
11:36:04 SRC=192.168.5.45 DST=66.109.5.138
11:36:03 SRC=192.168.5.45 DST=66.109.5.138
11:36:01 SRC=192.168.5.45 DST=66.109.5.138

If this happened more often, I would log all the bits on the network to look at with Wireshark. But, it is too infrequent.

A Guess

August 17, 2021. Someone who read this page suggested that the UDP port 137 traffic might be due to NetBIOS over TCP being enabled on the network interface.

Windows buries this setting pretty deep. In brief: get the Properties of the network adapter, get the Properties of Internet Protocol 4 (TCP/IPv4), click the Advanced button, go to the WINS tab and look for NetBIOS over TCP/IP. The reader said that when it was disabled, there were no more requests to UDP port 137.

This happens very rarely with my computers, but I did find a Windows 7 and Windows 10 machine which had recently sent data to UDP port 137. Neither had NetBIOS over TCP/IP disabled. Now they do. Each was set to get this setting from the DNS server, so I have no idea if that meant it was enabled or disabled.

And, it is not that simple. Each computer often uses a VPN and the VPN comes with its own network adapter and its own settings. I can not tell if the UDP port 137 requests were with the VPN active or not. That I saw a target IP address in the private 10 dot range means it may well have been with the VPN active. Another type of leak, perhaps. Also, when you close a VPN, it may well reset this in the real network adapter. After all, it does reset the DNS servers.

As before, the recent instances of this all happened in clumps of three requests in 3 seconds. A Windows 10 PC, tried to contact 52.242.101.226 which is a Windows Update server. A Windows 7 machine, tried to contact the internal-use-only 10.129.0.1 IP address. After my router blocked that, it tried to contact
194.37.97.33
193.27.15.14
193.27.15.11 and
38.104.37.97

 

Viewed 24,114 times since July 15, 2019 (12/day over 1,956 days)