Updated April 7, 2020:
Microsoft has agreed to buy corp.com from the individual owner to keep the domain away from potential buyers who may use it in cyberattacks, Krebs on Security reported. The seller did not provide Krebs with any details about the sale. “We released a security advisory in June of 2009 and a security update that helps keep customers safe," Microsoft said in a written statement to Krebs on Security. "In our ongoing commitment to customer security, we also acquired the Corp.com domain.”
Original article:
Depending on who winds up buying corp.com, administrators with Active Directory in their networks may wind up with sensitive information unexpectedly leaving the network. Now is the time to check the configuration to make sure they are not using the domain internally.
Microsoft's Active Directory, which provides identity management services, handles internal URLs using its own domain naming system (DNS) rather than relying on public servers. Users on the corporate network, behind the firewall, would hit Active Directory and get routed to the appropriate internal site. If Active Directory couldn't find the site internally, then the request would be sent to a public DNS server. This makes sense from a network routing perspective, since there is no need to leave the network to navigate to internal sites.
Organizations could technically use domains they didn't own (or didn't exist) for internal purposes.
That isn't really a problem, until a user tries to access the internal site from outside the corporate network—perhaps from home or a public WiFi network—and not using a VPN. Two things can happen: either the user will not be able to reach the site because there will be no corresponding record in public DNS, or the user will wind up somewhere else unexpected because the domain in the public DNS server points to some other entity.
That latter scenario is called namespace collision, a situation where domain names used on internal networks overlap with domains names that also resolve on the public Internet. This is something administrators should be concerned about.
Early versions of Windows that supported Active Directory, such as Windows 2000 Server, used "corp" (and "corp.com") as the default path for internal sites.
Basically, the machine outside the corporate network may have services running or fileshares open that reference the internal corp domain. Even off the corporate network, the machine will continue trying to access that internal domain in the background. Since Active Directory can't route that address, Windows will then look for corp.com. That may mean sending login credentials to internet network resources that use the corp domain to the external site.
It hasn't been a problem thus far because the domain doesn't go anywhere. The person who owns the domain, Mike O'Connor, hasn't done anything with the domain since he bought it in the mid-1990s. However, KrebsonSecurity reports that O'Connor is putting corp.com up for sale for $1.7 million, so now the question is who will buy it, and what could happen after the sale.
Whoever owns corp.com could potentially see all the searches, login credentials, and email addresses from all the organizations around the world using Active Directory.
This isn't pure speculation, as securiy researcher Jeff Schmidt, of JAS Global, looked at DNS namespace collisions using corp.com. Schmidt analyzed eight months worth of corporate traffic that was headed for corp.com (external site) and found more than 375,000 Windows PCs trying to send internal corporate information out to the external site instead of keeping it on the internal network. Information included attempts to log in to internal corporate networks and access specific file shares on those networks.
When Schmidt set up the domain to capture email, 12 million messages were delivered in an hour, many containing extremely sensitive information.
Schmidt discontinued the experiment and destroyed the data, calling the results "terrifying," Krebs reported.
Possible Outcomes
Someone with criminal intent and control over the domain can set up a phishing site to collect credentials or other sensitive information, or as a watering hole for companies that still has corp listed in its Active Directory to deliver malware.
Schmidt told Krebs whoever ends up controlling corp.com could have an instant botnet of hundreds of thousands of enterprise machines that can be exploited.
The ideal outcome is for Microsoft to buy corp.com, or for O'Connor to give the domain to Microsoft, so that it can be locked down. Neither scenario appears to be likely. Microsoft in the past had offered O'Connor $20,000 for the domain, according to Krebs. Another good outcome would be if an entity such as ICANN, in its role of managing and overseeing the domain name registration process, acquires corp.com and locks it down permanently.
“It seems to me that Microsoft should stand up and shoulder the burden of the mistake they made,” O’Connor told Krebs. “But they’ve shown no real interest in doing that, and so I’ve shown no interest in giving it to them.”
IT managers can remove corp from Active Directory, but it isn't as simple as just applying a software update or turning off a setting. The entire network would have to be taken offline to properly patch and change the configuration, which is unlikely to happen within large enterprises.
One way administrators can check to see if Active Directory is misconfigured is to take a machine outside the corporate network and check DNS query logs to see how domains are being resolved.
A good lesson here is to never, ever, use a domain that belongs to someone else. In Active Directory, don't use a domain that is currently non-existant (because someday it could belong to someone else) or owned by another entity, becuase of the risk of losing control over the namespace. Windows hostnames should use the organization's own domain, and internal machines and services should be named using subdomains.