I’m going to try and bring this blog back to life because the things I’ve been Going Through over the last year are finally starting to let up. And let’s start with a trip back to the forgotten year of 2019. Russia’s invasion of Ukraine was still limited to Crimea, Donald Trump was still tweeting whatever weird bullshit came to mind, and nobody could imagine the CDC fucking up its response to a disease that affected cishet white dudes.
More relevant to this post, though, 2019 was the year that Gearbox Software’s Borderlands 3 came out. This addition to the long-running series of “looter shooter” video games, despite generally good critical reviews, met with significant backlash from potential customers for two reasons: it used the controversial Denuvo DRM (which has since been removed), and it was being released on PC as an Epic Games Store exclusive.
Full disclosure: I don’t exactly have a high opinion of Epic as a company. I’ve purchased a total of one game from EGS using actual money, but I have grabbed as many of their free games as I could. Regardless, what was going on had nothing to do with EGS, but I felt obligated to point that out anyway because, well, gamers.
Of course, simply being on Epic Games Store and using Denuvo wasn’t enough. Borderlands 3 was a heavily anticipated entry in a rather popular series, which meant that for some reason people felt the need to come up with a better reason to not buy Borderlands 3 and/or shame people who did. And let’s be honest, people willing to make up complete nonsense to justify their own biases is not going to be hard to find on the cybertrons.
Now, most if not all of that screenshot was total nonsense and not even worth taking the time to debunk. However, there is one element of it that’s close enough to something that actually happened that I wanted to make it the focus of this Twitter post: the constant upload. Because there were circumstances in which Borderlands 3 was uploading stuff while people played. The first person to notice it, though, was doing so while streaming:
So, let’s look at this from the perspective of someone working in a SOC, because this actually makes a pretty decent case study. We have unexpected and possibly malicious network activity from newly installed software: is this actually a threat or is it expected behavior? Anyone who’s actually done SOC work knows that computers will do all sorts of weird stuff that isn’t actually malicious, and that you have to tune your SIEM detections accordingly. If you put a rule in place that watches for print spooler creation because of the PrintNightmare vulnerability, you’d want to make sure it wasn’t doing stuff like alerting on workstations because of the Print to PDF functionality in a fresh Adobe Acrobat installation. If you wanted to watch for unusual network activity from a Windows binary, you might catch stuff like msiexec.exe talking to a CDN to grab files for a software installation. Weird isn’t inherently malicious.
The question, then, is how one checks to see if these are false positives or not? The obvious answer would be to look up the IP addresses in the screenshot and see if you can figure out what they’re connecting to. And while they’re not fully visible, several still have enough to get a CIDR block out of them. “47.32.118…” means you can look up 47.32.118.0/24 in ARIN and be confident that you’ll get the same result that you would if you had the full IPv4, for example. And if you do so, you find out that the entire 47.32.0.0/12 range is assigned to Charter: a customer ISP, not a datacenter or anything like that. Same goes for “98.28…” (98.28.0.0/16 is also Charter), “108-95-11…” (likely 108.95.0.0/16, which is owned by AT&T), “2601:18b:…” (2601:18b::/32 is owned by Comcast), and “d24-36-1…” (likely 24.36.0.0/16, which is owned by the Canadian ISP Cogeco).
Now, to be fair, not all of these are ISPs; the 18.213.0.0/16 block (which includes the “18.213.20…” present in that screenshot) is owned by Amazon, as is the 52.54.0.0/16 partial address we see at the very bottom of the screenshot. Still, the idea of a DRM mechanism being dependent on connections to residential ISPs would seem peculiar at best. Especially when a better explanation appears further down in the Twitter thread:
If those residential IPs appear only when Twitch integration is active, that would be a good sign that the Twitch integration is the cause. The question is, why? What sort of integration would require connections to residential IP addresses?
The answer, fortunately, is a simple Google search away. Punching “borderlands 3 Twitch integration” into the search box brings up this page on the official Borderlands website, explaining exactly what the ECHOcast Twitch extension does. While most of the features aren’t particularly relevant or wouldn’t need a connection to the streamer’s computer, one feature of the extension does stand out as the most likely cause: Streamer Profile. Basically, it allows you to pull up all sorts of deal about the character: stats, equipment and inventory, skill tree choices, and session-specific stats such as Time Played and Enemies Killed. Anyone wanting to view this information would need to grab it from the streamer’s copy of Borderlands 3, either directly or by grabbing a copy that had been sent to Gearbox or Twitch servers by the streamer’s copy. Apparently Gearbox opted for the former.
If this was in fact a SOC, this would be the point in the investigation where we could flag the behavior as benign and move on to the next SIEM alert. There’s no reason to assume Denuvo was the cause of all those connections when there’s a far more plausible explanation right there on Borderlands.com. And investigating unexpected behavior takes work; blaming someone who already has a bad reputation doesn’t. (And to be fair, that reputation isn’t completely unwarranted, even if some of the biggest problems were eventually fixed.)
Again, weird behavior isn’t automatically malicious behavior. Sometimes, it’s just weird. And sometimes it’s the computer doing exactly what you told it to do.
