4

I just finished reading that the WannaDecryptor malware was querying an unregistered domain. I thought it was connecting to its command and control server. Is this correct?

It is my understanding that if a program of any sort attempts to connect to a server at an unregistered domain, the connection will fail - due to IP address resolution failure. Is that correct? If it's not, how is the IP address of the domain resolved? Or am I missing something?

Was the malware communicating with the control server using a configured unregistered domain? If it was, how was it able to without using DNS registration for IP address resolution?

| improve this question | |
  • 1
    I just finished reading ... using an unregistered domain for connecting to its command and control server. Where? I have not read that; it sounds incorrect. – user13695 May 15 '17 at 20:43
  • 1
    It is not using the unregistered domain for CNC comms. That's a misinterpretation of your reading of the article. – Joe May 15 '17 at 20:43
  • 1
    As others commented, the unregistered domain was not "CnC" - it was a sniff test, of sorts, for the malware to try and figure out if was being run by a researcher in a sandbox, and if so, not perform to hinder study. Sandboxes frequently report any foreign domain with 200 "up" for http requests. Since the domain was not registered, in the wild, lookup would fail, and ransomware would do its thing. But that means registering the domain to respond acted as a kill switch in this case. – JesseM May 15 '17 at 21:02
  • 1
    @Joe question has been edited to reflect the misunderstanding. Thank you. – jason May 15 '17 at 21:03
  • @JanDoggen updated question to reflect the misreading. – jason May 15 '17 at 21:04
13

As the previous two mentioned the malware wasn't connecting to the unregistered domain name. The unregistered domain was a technique that was supposed to be used to prevent analysis of the malware.

Often times when malware researchers are picking apart malware they do so in a virtual machine. The way certain virtual machines resolve domain names result in unregistered domain names being considered "resolved" to applications running on the VM. Advanced malware authors know this and so before they infect the machine they will often attempt to connect to random unresolved domain names. If these domain names get resolved then it signals to the malware that it is functioning on a virtual machine. If it detects this then it will abort and refuse to infect the machine. This makes analyzing the malware more difficult.

In the case of the WannaCry malware the author attempted to create a similar countermeasure, but did so incorrectly. He hard coded the unregistered domain names. So once the researcher pointed the hard coded domain name to a DNS sink all the infected computers thought they were infecting a VM. So instead of starting the encryption process the malware just exits to prevent further analysis.

Had the author randomized the domain name check, registering the domain name would have done nothing.

| improve this answer | |
  • 2
    Thank you for clarifying my understanding. Any info/links/leads on how VMs resolve domains would also be appreciated. Thanks again. – jason May 15 '17 at 21:14
  • 3
    VM environments used to inspect malware will often "shim" calls that make external resource requests (like DNS lookups, etc.) and return dummy data no matter what the DNS call is. In this case, the code is EXPECTING the DNS lookup to fail but in the sandbox it wouldn't, and thus it would exit (hampering scanning) – Joe May 15 '17 at 21:19
  • 1
    @Joe Is there a wiki Article or a given name for this VM "feature" to read more about it? – Azteca May 15 '17 at 22:38
  • 1
    It's not really a VM feature as much as a malware sandbox feature. Example: zeltser.com/fake-dns-tools-for-malware-analysis – Joe May 15 '17 at 22:41
6

In the case of WannaCry, the unregistered domain acted as a kill switch.

The code did the following:

  • Issue HTTP GET to unregistered domain
  • If the GET request fails (because it's unregistered) proceed doing damage
  • If the GET request succeeds then abort

This gives the attacker the ability to stop their own attack once it's in the wild by simply registering the domain.

During the WannaCry V1 attack, a malware researcher observed traffic to the unregistered domain, registered it, and pointed it to a DNS sinkhole. He did not know this would stop the attack.

This is quite different than a Command & Control (C2) server which wants to establish a connection in order to control remote machines.

| improve this answer | |
  • Thank you for the response, I edited my original question to clarify what I was asking. How was the malware using the unregistered domain? It said in the article the malware was sending traffic to it. – jason May 15 '17 at 20:32
1

That was not a connection to a control center. This was in all likelihood an attempt to prevent analysis in a virtual machine.

Some malware sandboxes/virtual machines will intercept all outgoing HTTP requests and 'reply' as if they are the server in question. By using a non-existing domain, Wannacrypt knows that any 'valid' response indicates that it is running in such an environment. It can then e.g. abort its operations.

For more details, read the blog post of the person who detected this, or the Talos write-up.

| improve this answer | |
  • My question, which I'll amend, is how was the malware connecting to the control server using an unregistered domain? – jason May 15 '17 at 20:29
  • The malware was not using the unregistered domain for C&C comms – Joe May 15 '17 at 20:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.