[kemonocode]

That's frankly alarming. They should be doing nothing but static analysis on those binaries and if they must execute them, then certainly not giving them any network access. That's without even touching on any IP law concerns and how an end user can be unwillingly complicit in such things...

[dahdum]

Malware will pull updates and commands from the internet, if they didn’t allow network access it would be near useless of a service. Attackers can make the binary pre-update look as innocent as they want.

[Bartweiss]

I can understand why people are saying that network access is necessary for meaningful execution, given how much malware conditions on it. (For instance, WannaCry's kill switch.) But it's still hair-raising from a developer's standpoint since network actions you expected to control are now triggering unexpectedly. I can think of a few ways for that to get ugly.

In this case Beacon was sandboxed for security observation, but a build could easily be sandboxed for network-unsafe testing instead. Perhaps it's issuing malformed or high-volume requests to test internal functionality, safe in the knowledge that it's not actually connected to anything, and so it becomes a DoS attack when it's launched in the wild.

Or worse, maybe it's calling home to an endpoint that does something when it gets the call. It's not hard to imagine somebody putting together a binary with any required auth baked in on the logic "this only exists on my machine", and then suddenly getting it called from Redmond as well. Best practices ought to handle that alright, but it's still an awfully surprising thing to have happen to your test build.

[LorenPechtel]

Malware often checks to see if it has internet access and doesn't activate if it doesn't--to keep it from running in a test environment.