0

I was working on a rule that reports phishing sites, and I wanted to exclude known domains, such as .microsoft.com etc, and a doubt arose: can someone register a subdomain of a known site to phishing purposes? I came across this article, where there is a video demonstration. So, 2 questions:

  1. Is it possible to register a subdomain of a known company for malicious use?
  2. In the video, I imagine that "under the hood" two queries are sent, one to the legit site, the other one to the malicious one; if I have a rule, like a firewall rule, prohibiting communication with domains that are not legit, do I avoid the threat exposed in the video?
Pleasant94
  • 103
  • 1
  • Your first question is already answered and the process even has a name given in the article. https://www.google.com/search?q=subdomain+takeover answers can be found here: https://security.stackexchange.com/search?q=%5Bsub-domain%5D+takeover – schroeder Dec 04 '20 at 16:44
  • How do you "write a firewall rule" to block illegitimate subdomains? If you know what to block, then just block them. I don't know what you are asking in the 2nd question. – schroeder Dec 04 '20 at 16:47
  • What you show is not registering a subdomain. It boils down to: in the past company X did `whatever.companyX.example CNAME someotherresource.atprovider.example`. Sometimes later `atprovider.example` is expired and deleted. Anyone registering that domain, has then control of `someotherresource.atprovider.example` and hence "controls" the name `whatever.companyX.example` because of the CNAME. The "attack" is trivially thwarted if `company.example` takes care of cleaning its zone and removing `CNAME` (and others like `MX`, `SRV`, etc.) that are not needed anymore. – Patrick Mevzek Dec 04 '20 at 17:05
  • @PatrickMevzek While true, everything you just said is a red herring. No, sub domain takeovers are not the same thing as a malicious attacker registering a subdomain of a trustworthy domain - such a thing isn't even possible, since you don't register sub domains. However if you take over someone else's subdomain then you can use it to send spam, which is what the OP was asking about. – Conor Mancone Dec 04 '20 at 19:01
  • As for this attack being trivially thwarted, the reality is that many companies have "hanging" subdomains that are vulnerable to take over, and such things have been used in phishing attacks and other styles of spam – Conor Mancone Dec 04 '20 at 19:02
  • @ConorMancone I am just paraphrasing the linked document and explaining what is happening, that is all. I started my comment by "what you show is not registering a subdomain". And as for "As for this attack being trivially thwarted" I said so because there is not a real vulnerability here. It is a configuration/maintenance issue and just realizing that **obviously** as you use external resources (either at email level, DNS level, BGP level, specific records such as CNAME, etc.) you are of course at the mercy of those resources. It is "just" one form of dependency tracking. – Patrick Mevzek Dec 04 '20 at 19:16

2 Answers2

0

Two separate items come to mind here: Hijacking of existing subdomains and creation of new subdomains. (I'll skip the obvious third item: take over an existing subdomain's host.)

The links in this question refer to hijacking abandoned subdomains: an attacker can take advantage of an existing subdomain that was defined as a CNAME to another domain that was available for registration. Simply register that other domain and accept mail for the CNAME and you can gain an SSL certificate. Your rogue host will work until the domain owner yanks the CNAME.

Creating a legitimate domain's subdomains can be done by hijacking its DNS (e.g. phishing their GoDaddy credentials). This is known as domain shadowing:

Domain shadowing is the process of gathering domain account credentials in order to silently create subdomains pointed at malicious servers without tipping off the actual owner.

This technique is most commonly used to compromise small less-tech-savvy sites since the site admins aren't likely to notice (they'd have to log into their registrar and notice a new subdomain is present). It's not at all likely to come from a domain like microsoft.com, which is big enough to have an information security team protecting it.

Adam Katz
  • 9,718
  • 2
  • 22
  • 44
0

As others have noted, otherwise legitimate DNS domains may be compromised and abused to serve malicious DNS records as subdomains. There is a service space in the underground economy for this, driven largely by the incredible success of credential theft from phishing campaigns, malware assisted password theft, or credential reuse over the years. Most registrars don't incentivize customers to use strong authentication options, and many don't offer MFA options. So as a result, the systemic abuse of hijacked DNS domain holder accounts for creating and controlling rogue A records, commonly termed domain shadowing, has been a thing since at least 2010.

Attackers do this because it's free DNS infrastructure, and it provides them with positive reputations and blacklist avoidance.

Food for thought: this weakness in domain trust affects other aspects as well. Consider an attacker that has hijacked a legitimate domain, created a rogue A record that points to a web server they control, and has also picked up a domain validation certificate for the malicious FQDN. Any visitor to the exploit kit, phishing page, or web skimmer operating on that malicious FQDN will get a positive validation from their web browser indicating the legitimacy of that site. It is in fact legitimate, from a domain validation perspective, because the entity saying they're in control of the DNS name (the attacker) is very much in control of it. The thumbs up from the browser, rooted in strong cryptographic models, is also compromised by the loss of a single set of weak or stolen credentials.

Additionally: the concept of big companies with security teams monitoring things being outside this threat model is shaky. It seems to have more to do with which registrar you use and what authentication and authorization controls you have in place for those services.