Hacker News Reader

Comment by Laforet | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com