The theory is that the malware wouldn't execute in sandboxes for malware analysis, since the analysis environment will accept all connections from the sandbox.

So, if connection = successful, then we're being analyzed and don't execute.

If connection = unsuccessful, then we're on a real workstation, execute!

Then the scheme fell apart when someone registered that domain, so all connections = successful and malware will not execute (but machine still infected).

Probably to prevent it from fucking their own computer network up. Just change your local resolver to be authoritative for the domain(s) in question, and bob's your uncle.

But next they'll likely use more domains, and more expensive ones, so that random security researchers can't just expense the registration on the corporate credit card. I know .ng costs 50k, but .np might be pretty comical to deploy if you're not really worried about a global off switch.

If that's the motivation, just use a non-existant TLD, or, even better, .local

If the motivation is to have a killswitch, you don't want something expensive, because the attackers would then have to pay for it if they want to activate it for whatever reason.

.ng domains cost a few hundred bucks per year, the times when they cost >10k are long gone

The motivation for the domain check is to see if you are in a sandbox environment, and if you are, don't do anything. If you read the article, he talks about this.

The end of the article suggests it's an attempt to detect sandboxed environments that fake all domains.

I don't think that's a thing. And certainly not a common enough thing to use as a sandbox evasion technique. The sandbox is either connected to the internet or to a proxy that replays past connections.

Seems like a reasonable thing to do on a sandbox specifically set up for the purpose of analyzing malware. It's not helpful to just block all connections, because you want to see what it's trying to connect to and what it's trying to send there. You don't know what it's going to try to connect to, so you can't redirect only specific things. Letting it connect to the actual internet is obviously just crazy. Redirecting everything to an internal honeypot sounds pretty reasonable.

Maybe I'm wrong, but I would guess that sandbox evasion techniques aren't intended to stop one-off reverse engineering, but rather to get around the bulk programmatic analysis that Google or FireEye does. Those require an internet connection or a replaying proxy because a lot of modern malware comes as a minimal package that downloads its payload from the web.

I would hope sandbox environments aren't connected to the internet, spreading malware to others while your doing your research.

A responsible researcher would have a fully isolated, both from the corp net, and the internet. Then will slowly being to allow connections out as they can confirm that's not how it's spreading...

Many sandbox environments resolve whatever they're queried for with the same IP address. This is addressed in the article.

How many ISPs spoof failed DNS queries so they can feed you ads? That alone would make this useless as an evasion technique.

It means the malware would not execute for users on those ISPs because they false-positive for being a sandbox; that doesn't make it useless unless every ISP is doing that.

OTOH it means that laptops won't activate until they are on a work network, for an SMB worm that's probably not a bad strategy.

Clearly not that many considering how well it did manage to spread.

Somebody else hijacking the c&c servers?