Hacker News Reader

Comment by johnchristopher | Hacker News Reader

> After about 5 minutes the employee came back with the news that the registration of the domain had triggered the ransomware meaning we’d encrypted everyone’s files (don’t worry, this was later proven to not be the case), but it still caused quite a bit of panic. I contacted Kafeine about this and he linked me to the following freshly posted tweet made by ProofPoint researcher Darien Huss, who stated the opposite (that our registration of the domain had actually stopped the ransomware and prevent the spread).

That's quite an high abstraction level programming thing to do to use a domain name registration state as a boolean. Is that a regular thing ?

View on HN

I believe the malware was designed to do that as part of a way to test and see if it's in a sandboxed environment if someone was trying to analyze it. If I understood this correctly, checking the domain was a way to do that (although I might be completely wrong).

Can somebody explain how this will work? AFAIK it does not even check for obvious things such as vmware processes running in the background.

It was explained quite clearly in the article. Sandboxed environments will generally have a catch all that replies to any IP requests with a sinkhole server. To prevent analysis, it'd do a lookup to a known unregistered domain and if it got back an IP address (which should not happen except in the sandbox with an unregistered domain) then it quits because it assumes it's sandboxed and being analyzed.

I still can't understand how the malware authors could be so smart (or, if not smart, at least competent enough to build ransomware from scratch, make it wormable with ETERNALBLUE, and launch a massive and effective spam campaign) and yet so stupid.

They could've achieved the same sandbox detection effect by just registering the domain and pointing it at 1.1.1.1 or whatever. The non-sandboxed connections would still fail, and no one else could take the domain.

I don't think the creator would be too keen to create anything unnecessary that could be linked back to them through a paper trail.

I find it interesting that they didn't randomize a couple of long strings and tried to resolve those instead like the article mentioned has been done in the past

They could've achieved the same sandbox detection effect by just registering the domain

That would leave a paper trail, potentially revealing who's behind the malware.

You wouldn't do that with a .com domain, rather with a .local domain or such.

I would guess that a simple DNS/HTTP works just as well. In contrast checking for vmware processes or similar would probably result in a code signature that can be picked up much more easily by malware scanners.

Sometimes sandboxes resolve all DNS, so if you point to to a nonsensical URL and it resolves, then you may be in a sandbox.

More likely used during testing by the author itself?

I'm not really sure what you're trying to say, but reading the rest of the article will answer your question.

It's a fairly regular thing. If you are a Google Chrome user, then your WWW browser has been doing much the same check, for fairly similar reasons (detecting whether it is running inside an environment where DNS service is being generally altered to redirect clients to a special server), for the past half decade.

* https://mikewest.org/2012/02/chrome-connects-to-three-random...

I think that it is more likely that there was meant to be something else on the other end which did something but x0rz got there first so it broke.

I think a distributed global database is a more appropriate analogy.

This may well give birth to a new paradigm: Domain-Driven Programming.

Each condition is satisfied by a different domain lookup.

Wow, now, let us imagine using aggregation of millions of states of human minds as a Boolean constant used in millions of scenarios for about four years straight.

Reply on news.ycombinator.com