I wonder if whitelisting the server would work then.
It looks like they own 137.221.96.0/22. I’d like to get a blue’s confirmation before I WL it. I also can’t help but wonder what they are sending that is tripping trojan traffic signatures. I’d like to wireshark it, but the error is so rare, from a packet perspective that I don’t think i’d ever capture it.
I’m going to dig through my threat log and see if I can find something similar from my server.
I’m having a little issue accessing my alerts… might need to restart my controller vm or something.
It looks like it isn’t just me.
This just happened again and correlated to the second with an IPS malicious traffic signature.
24.105.33.197 : 3724 INTERNALIP : 61887 12/20/2020 10:16:49 PM
Concerningly, this time a different network range in a different part of the world. Unless blizzard decides to take action, we are going to be left with the choice of disabling IPS or suppressing these IP by IP.
I have been attempting to catch it but have not seen the issue yet tonight. As in I have not dc’d yet tonight… still trying to catch it. Hopefully we can both confirm it.
Knoest is probably tired of getting update notices for this thread, but I wanted to add a comment just incase we get a blue reading this.
While I can only be certain that this is happening on Ubiquity hardware, it is reasonable to infer that this will be happening on any high end home networking equipment and virtually all corporate equipment that support DPI and IPS signature detection. In short, this may be impacting a large number of users.
1 Like
ive seen DPI screw up perfectly clean SMTP traffic because it thought an image in the footer (that had been in there for over a year) was now malicious due to signature matching - giant pain in the you know where because the rule was set to silently drop (which is ultra stupid in a commercial environment)
can you report the false positive to the vendor?
It was reported in the ubiquity thread I linked. In looking into it further it seems to me that blizz might be initiating a connection remotely to ‘push’ certain data, triggered from your active connection. If I’m not mistaken, that is bad practice and not too shocking it matches a malicious signature – just like any RAT or reverse shell. I’m not too sure what Ubiquity or other vendors could do other than exclude the wow protocol. It also seems like blizz is aware of the problem, but is blaming firewalls generally ("transfer aborted: instance not found” in Shadowlands - #4 by Illìdàn-barthilas)
Finally caught it. The exact same moment I dc’d…
Threat Management Alert 1: A Network Trojan was Detected. Signature ET TROJAN Netwire RAT Check-in. From: 35.232.127.122:3724, to: 10.0.1.152:58003, protocol: TCP
although this is a google cloud IP I assume it’s being used by blizzard since it’s the same exact log you have at the same exact time I DC’d. Also .152 is the computer I play on… so it all lines up!
Hey again,
Thanks for the update Knoest, glad to see that you and Solania were able to figure out what was triggering the connection issue. Hopefully since this has been reported to Ubiquity they may be able to make some adjustments to DPI threat detection to prevent this in the future. Ubiquity devices definitely aren’t your run-of-the-mill home routers, so I could see how not very many people would be affected by this or notice it at all since the vast majority of WoW players wouldn’t be running that type of equipment.
You are correct! With the launch of Shadowlands WoW is now leveraging GCP (Google Cloud Platform) to host world/instance servers as needed, so it is expected to see some Google IPs show up. Port 3724 is the main WoW port.
That thread is actually for a different problem entirely and not related to what is being discussed in this thread. We know that firewalls can sometimes cause problems, but it’s definitely not something we would jump to without doing some basic troubleshooting/investigation first.
I am kinda wondering what it is yall are sending that appears to be a remote access tool though… kinda makes the brain wonder a bit and all ya know.
1 Like
I was directed to this thread from a post I made about what appears to be an identical issue. Did you folks find relief from whitelisting some IP addresses or did you have to disable IPS altogether? I’m on a UDMP, and I’m seeing a few different IP addresses with the same port, which appears to be Blizzard. I feel like I need a list of IPs to whitelist for it to make a difference, absent disabling IPS altogether.
Oh my god thank you thank you thank. I was about to throw my PC out my window. And given the shortage of GPUs these days, I may have stopped playing WoW completely. But I have Ubiquiti gear, and I have IPS enabled, and I am SUPER HOPEFUL you guys are onto the problem. I just checked my IPS logs and found:
04/12/2021 3:32 pm Malware ET MALWARE Netwire RAT Check-in 34.123.149.90 : 3724 192.168.2.55 : 51799
This is the exact time that my dungeon “froze”… all graphics working fine, able to chat with team, but no one else is moving.
I WILL REPORT BACK!
Damn… look at the log from yesterday. I was actually RAGING with the “freezes”
| 04/11/2021 8:42 pm | Malware | ET MALWARE Netwire RAT Check-in | 35.226.216.87 : 3724 | 192.168.2.55 : 51513 | SUPPRESS |
|---|---|---|---|---|---|
| 04/11/2021 7:07 pm | Malware | ET MALWARE Netwire RAT Check-in | 34.72.65.159 : 3724 | 192.168.2.55 : 64897 | SUPPRESS |
| 04/11/2021 6:58 pm | Malware | ET MALWARE Netwire RAT Check-in | 34.72.65.159 : 3724 | 192.168.2.55 : 64680 | SUPPRESS |
| 04/11/2021 6:18 pm | Malware | ET MALWARE Netwire RAT Check-in | 24.105.35.226 : 3724 | 192.168.2.55 : 62049 | SUPPRESS |
| 04/11/2021 4:28 pm | Malware | ET MALWARE Netwire RAT Check-in | 24.105.36.37 : 3724 | 192.168.2.55 : 59282 | SUPPRESS |
| 04/11/2021 3:22 pm | Malware | ET MALWARE Netwire RAT Check-in | 35.193.56.200 : 3724 | 192.168.2.55 : 56194 | SUPPRESS |
| 04/11/2021 12:36 pm | Malware | ET MALWARE Netwire RAT Check-in | 24.105.33.158 : 3724 | 192.168.2.55 : 49898 | SUPPRESS |
| 04/11/2021 12:14 pm | Malware | ET MALWARE Netwire RAT Check-in | 24.105.33.158 : 3724 | 192.168.2.55 : 49533 |
Problem is solved after suppressing this rule! Thank you so much.
2 Likes
Ah that’s amazing! I just checked this thread and noticed you had a fix. Now I can dump my vpn and lower the ping a bit more! Thanks for the fix!
I am having a similar issue where the game freezes, but running on the spot happens. I don’t have the same hardware as the above players, is there a fix for those of us without Ubiquiti hardware?
Post a winmtr. We can’t diagnose without data.
Same problem here. TPLink Archer AX6000, started about 3 weeks ago. Happens in and out of dungeons, raids, open world.
Just reproduced it after 2 hours of play. MTR report below:
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| TP-SHARE - 0 | 3073 | 3073 | 0 | 0 | 17 | 0 |
| 24.105.62.129 - 0 | 3073 | 3073 | 1 | 4 | 206 | 3 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider
As you can see, it’s fine.
I turned off the SPI firewall on the Router. Next step is disable Windows firewall.
I can’t imagine Verizon FIOS is doing this because if they were, the forums would be full of it.
Posted this in another related thread but copying here as well:
Apologies for somewhat necro-bumping this, but I’ve run into the same issue recently. After getting partial DC’d like this several times during M+ runs, I’ve gone and aggressively whitelisted most of the subnets in Blizzard ASN (AS57976). The following subnets are what I’ve whitelisted:
24.105.0.0/18 (US)
37.244.0.0/18 (EU/US)
59.153.40.0/22 (JP)
103.198.32.0/23 (AU)
137.221.64.0/18 (EU)
158.115.192.0/19 (US)
185.60.112.0/22 (EU)
198.74.32.0/21 (US)
Blizzard is also leveraging GCP (Google Cloud Platform) now with Shadowlands, so there’s some non-Blizzard IPs that have been tripping this as well (search logs for port 3724 on one end). I didn’t want to disable all IPS for everything on GCP, but without knowing what allocation Blizzard has there, it’s hard to cover everything.
As a compromise, I added a signature suppression for “ET MALWARE Netwire RAT Check-in” and “ET MALWARE Backdoor family PCRat/Gh0st CnC traffic (OUTBOUND) 103” (the two signatures I have flagged in my logs) for 34.64.0.0/10.
N.B. this is a rather large IP range, covering 34.64.0.0 - 34.127.255.255. These are all GCP IP addresses, but Blizzard does not control what’s on the vast majority of this IP space. I determined this to be an acceptable risk. Most of the subnets are part of AS15169 (GOOGL-2 / Google LLC), but some are in AS139070 (GOOGLE-CLOUD / Google Asia Pacific Pte. Ltd.). There are also many other networks in AS15169, but until I see any Blizzard traffic from them, I’m opting not to add them.
References
https://bgpview.io/asn/57976
https://bgpview.io/prefix/34.64.0.0/10
2 Likes