Four Ways to Know Your Organization Is Mitigating the Risk of Subdomain Hijacking

WEBINAR TRANSCRIPT

Disclaimer: Please be advised that this recorded webinar has been edited from its original format, which may have included a product demo. To set up a live demo or to request more information, please complete the form to the right. Or if you are currently not on CSC Global, there is a link to the website in the description of this video. Thank you.

Christy: Hello, everyone, and welcome to today's webinar, "Four Ways to Know Your Organization Is Mitigating the Risk of Subdomain Hijacking." My name is Christy DeMaio Ziegler, and I will be your moderator.

Joining us today is Mark Flegg. Mark is responsible for advising a client base on digital risk and preventative measures brands can take to safeguard their digital assets. To raise awareness of digital threats to businesses, Mark presents programs dealing with the domain security and cyber security assets at leading industry conferences and events. And with that, let's welcome Mark.

Mark: Thank you, Christy. Hello, everybody. Thanks for joining today. So we've got, I think, a good agenda that's going to help educate if you need that and essentially figure out how you can mitigate this recent threat and risk that we have in the industry. So today what we'll cover is the four ways to ensure your organization is mitigating the risk of subdomain hijacking, and that is essentially: understanding the risk, so we've got a little video to play for you; realize the history of "dangling DNS," how has it just happened now kind of thing, why is it a big deal; how you can mitigate it; and then we can learn from our Hijacking Vulnerabilities Report that we produced, which will give you some inside information. So with that, let's watch the video.

Narrator: Global businesses rely on the internet for everything, from emails, websites, authentication, and voice over IP. Throughout the year, businesses launch promotional websites, service announcements, and applications. Before users can reach the destination website to access content, there's a process that must be followed.

First, the website owner will engage with a web hosting provider to request a landing page for an upcoming promotion. Next, they will reach out to their DNS administrator or IT team to make that connection. Behind the scenes, there's a lot more going on than meets the eye.

In order for the site to display live content, they need to connect the dots, which is the DNS. When the campaign is over, the marketing team will realize that the website is no longer needed and will remove it by going to the web host. The marketing team doesn't realize that they need to also go back to their DNS team to remove the DNS record. The DNS record that was used to map users to the destination is left behind, referred to as "dangling DNS." Over time, these DNS records will accumulate and can be used against victims in an attack known as subdomain hijacking.

Cyber criminals crawl the web asking, "Where does this pint to?" They can go to the web hosting provider and ask for a specific host name as long as it's not in use, no questions asked. Cyber criminals will use dangling DNS records to display their own malicious content. They can easily set up their spoof website and attract genuine traffic for their fake content using the host name no longer in use. Security protocols that detect bad actors and their activities are circumvented by this method. Security teams can't detect a breach, and end users can't tell the difference. Cyber criminals can even get a free domain validated digital certificate to add the HTTPS padlock to seem more authentic.

With time and business growth, more of these "dangling DNS" will accumulate, and teams will hesitate to delete DNS records they are unfamiliar with. It's a challenge for enterprise organizations to manage assets outside the firewall where there are a variety of complex external attack surfaces.

CSC has developed a Subdomain Monitoring solution that provides comprehensive analysis and daily alerts to any change in state, allowing you to quickly take action and remove the offending "dangling DNS" record, receive full reporting on all your DNS zone records daily, and finally get some closure to this vulnerability that is very difficult to manage across departments. Secure your organization's continuity, reputation, and revenue with CSC's Subdomain Monitoring.

Mark: All right. So hopefully, that wasn't too fast-paced for you, and you kind of get the gist of what's going on here. It is complicated, but it's simple at the same time, and it's only simple if you know it. So what I thought I would do is kind of just go through, well, how has history created kind of ?dangling DNS."

If you go back to a point in time, 2005, we all used our own internal data centers. This was the first thing that we did as we kind of got on this journey of discovery to get businesses online. It has been a 20 plus year journey so far, and we're still figuring it out, right? And during that time, we've come up with different solutions. There's been innovation, different tools available to us. And, of course, cyber threats have meant that this is always constantly evolving as well. We have to be ahead of them.

So if we fast-forward to something like 2010, it was deemed that, "Well, hang on a second, we've got a lot of the investment for these data centers. Does it make sense to go to an external?" We get a more cost-effective solution. It's somebody else's core competence. Therefore they're going to invest in security and all the rest of it. Going from no threat, where it was our data center because we're not going to give up our IP addresses or CNAMEs to a third party, why would we, moving to the external did introduce a limited risk in that whoever we partner with, they may recycle host names and give it to somebody else. But it was more a commercial relationship when you're using these external data centers, and cyber criminals, they don't typically like to go near those kind of relationships.

So we fast-forward again to kind of certainly now, and I think the biggest push we saw was from 2015, where people were now using another external data center, but we call it the cloud. And this is where you've got the highest risk of subdomain takeover. I think the cloud providers that are out there do a terrific job at the web hosting, but they do operate like a retail organization in that they are there to sell hosting packages amongst other services that they offer. So if I'm a cyber criminal and I want a host name, I go ask for it, and if it's available, I can get it. And that means the subdomain takeover has occurred.

So it's important to understand how we're creating these "dangling DNS" records. If we haven't got good zone cyber hygiene internally, and not to pick on any department, but if marketing fails to tell the IT team to remove a record that's no longer required, well, that your "dangling DNS" record right there. So we've seen a massive uptick over the years of people moving, that are having that transition to the cloud providers.

We're not the only ones that noticed it. For those familiar with ICANN, the Internet Corporation for Assigned Names and Numbers, they issued a rare update just over a year ago because they were worried about this. They had also seen the issues. And ICANN don't make statements lightly. So when they do, you really should be paying attention to it. But they were talking about "dangling DNS." They saw some of the impact that was happening across the different industries.

So the question on everyone's lips hopefully is, "How do you mitigate subdomain hijacking?" It's pretty simple. If you haven't got a resource record that is dangling because you've deleted it, the risk goes away. So what we've learned is the cyber criminals do feed on our mess. Destiny is really in your own hands here. They are powerless if you've got good cyber hygiene.

Now getting to grips with it isn't easy. We're dealing with this kind of 20 plus years journey we've all been on. We haven't documented as we've gone along because we were still trying to figure it out. So it's not the easiest thing to do. But like every big problem, if you break it down into manageable chunks, it does become easy.

So the first step would be to review and remove unwanted legacy records. That's what we say baseline it. Where do we need to be today as custodians in our roles right now? Unfortunately, the 20 years of noise that's built up is on our watch. So we're the ones that have to clean that up, and we can baseline it.

And then the second part is, right, well, we don't want to have to do that again because it was probably a painful exercise. We really do want to keep on top of it. So you need daily monitoring of your DNS resource records. And we say "daily" because obviously, as a DNS provider, we see a lot of data mining activities out there. And cyber criminals are looking. So it's like anything else in this world. The longer it's in the wild, the more chance somebody has got of noticing it, and then they will exploit it. So you really want to keep on top of this on a very frequent basis. These resource records, they change daily.

And then, obviously, you want alerts for new instances. So, for example, if something was on a status 200 yesterday, today it's a 404, your staff, your customers, your internal monitoring and alerts are not screaming at you, chances are this is a deliberate content removal. We've created a "dangling DNS" record. We need to take an action.

Now some customers have gone a step further that are subscribed to the service. They've implemented a new policy, which is essentially if I find something, for example, on a 404 status for two days or more, I'm going to delete it. And they'll issue that policy to the business. Obviously, they'll share the data with them. But once that policy comes to be, they might give them three months to clean things up, then they can go ahead and just do that and they can keep on top of it. So I think it's, again, something that must happen. Waiting for people to make decisions or not even being able to ask people the question, "Do you need to keep this resource record," is dangerous because it just sits there, and our default decision is do nothing. We don't know what it's used for. And cyber criminals will jump on that.

So how you can learn about this, we did some analysis across our DNS records. We've got over six million DNS records. We did apply a filter to look at where they were pointing to a third party or cloud provider. And astonishingly, 21% of the records that had a subdomain did not resolve, and that could leave companies vulnerable to subdomain hijacking. And there are different status codes in amongst that. But it's one in five not resolving. That's a scary statistic.

Sixty-three percent were showing error codes, such as "404" or "502 bad gateway." And unless somebody on the call today can educate me, I don't know a valid use case to take the time and trouble to create a subdomain for it to go to 404. 403 perhaps, but not a 404. So we just need to clean house and get rid of these. They're not resolving. They're not doing anything.

I think zone cyber hygiene, again over this past 20 years, is probably one of the worst house-kept items in business, and that's saying something. But what do you expect? We've been on this journey, different owners, policies, vendors for DNS, and then the inherent fear of deleting anything that we're not sure about. It is a significant challenge, but we have to draw a line in the sand at some point because cyber criminals have woken up. They're aware of it, and they're looking for it to exploit.

So where we see this outsource of web hosting to the cloud, you can see we all manage more DNS records than we ever have done. DNS is being used for absolutely everything now. It's not just your websites and your email. It's VPN. It's your email policy for SPF, DKIM, DMARC. It's your Office 365 cord, any Google authenticate. I mean just a whole host of things.

And where we've outsourced to the cloud, what we've realized is, if you look at this figure here, many of the companies analyzed seem to be doing a better job at consolidating subdomains under just one or two cloud providers. However, they've got much smaller portfolios that are more easily managed. Conversely, 11% of the companies analyzed in this research used five or more cloud providers, and those companies account for more than half of the DNS records analyzed. And the majority of them have larger portfolios with thousands of records. So I think what it's showing is that companies with large portfolios may not have centralized management of their cloud providers, and that makes it a challenge for them to have good oversight of all of their DNS records.

I've been in this industry for over 20 years now, and when we started, it was kind of the whole domain registrar, people had multiple domain registrars, especially for a global organization that was decentralized and everybody made their own decision across the world. I think business is doing a better job of consolidating that and having one policy. Cloud providers, it's like back in the old Wild Wild West days of domains. It's like, all right, we'll use Cloudflare, we'll use Akamai, we'll use AWS, we'll use Microsoft, and that's kind of born out in this illustration here. We've got a lot of cloud providers with a relatively even split.

So what if it's not addressed, if we let these issues fester? Well, even Microsoft have fallen foul to it unfortunately on their own Azure platform with their own subdomains. So the main thing is phishing and malware essentially. Once somebody gains control of your content, which is what they're doing inadvertently with the cloud providers, your resource records, CNAME, or A record is still pointing to it, they will use that in their phishing email campaigns.

And for a cyber criminal, it's extremely valuable because that's got a much higher percentage of getting through all of our intrusion detection systems, IDS, email gateways, spam filters, you name it. And that means it gets delivered to somebody's inbox. And even if somebody has had phishing awareness training and what do we tell them to do with links in an email, hover over the URL. Do not click on the URL. Hover over it and look at the right-hand side. Is that the domain name you're expecting to go to? Because they're passing themselves off as yourselves, the answer is yes. So it's incredibly easy for them to get more visits to their site. And obviously data theft, stolen credentials, and financial loss are three of the other big things that can occur here.

But for a cyber criminal, all the questions that we ask, all of the systems that we've got in place, they're all kind of bypassed if they're able to do this. Is the domain fraudulent? No, it's owned by us. All right. Is it on another DNS that could have been hijacked? No, it's on the same DNS that we use for all of our other domain names. Okay, so it must be a suspicious web provider. No, it's on, as an example, AWS, and that's who we use for all of our other web properties. So there are no bad signals coming off any of this that allow me to understand that this is a malicious site.

Even with the browsers now, Chromium, Firefox, they all look for the presence of a certificate, an SSL certificate. Well, a cyber criminal can go to Let's Encrypt and get a free certificate and put that on there to lend authenticity. So again, I'm not seeing anything bad here. It's got a certificate. Google aren't going to flag it up. Mozilla aren't going to flag it up. So again, it all lends into this is legitimate.

Once the user clicks on the link, it's game over for whatever the cyber criminal intended. And we've seen everything. We've seen the spoofed sites obviously. I've seen adult content. I've seen online gaming, online gambling. Just a whole host of things that they do, including your more traditional, ah, look, this is downloading malware. So it's super important that we protect this and protect the users.

And this is where we have a layered security approach. I think anyone that's attended my webinars before will be familiar with this screen, hopefully with this slide. It is a multilayer approach that we have to do, defense in depth strategy. So first you've got to use enterprise class providers. They're going to mirror what your organization is trying to achieve in terms of the policies around the system, the staff, and processes.

It's table stakes now that you've got secure portal access, whether it be single sign-on, federated identity using SAML 2.0, or things like two-factor and IP validation. And then constant review of your user permissions. A lot of companies will just say, "Ah, give them access to everything." They're a trustworthy user. There's no reason you can't do that. But at the same time, what if they become compromised? Whilst we do everything in our power to stop people breaching our systems, even if one of your users succumbs, we have multifactor and federated identity, nothing is completely secure. So controlling those permissions is super important because if one of your users does get breached or compromised, then you want to limit the damage that that cyber criminal can do when logging in to a system. And that's not just for us. That's for any system, any third-party system you're using.

And then, obviously, when it comes down to the domain level, if it's business critical, you should be considering MultiLock, DNSSEC, DMARC, CAA records for those business critical ones. Again, it's giving you those extra layers of defense.

We do like to consider ourselves as the most security conscious domain registrar that there is. You can see the evolution of our security focus here, going back to 2012, when we introduced IP validation. Then we brought in MultiLock or Registry Lock as a lot of you might know it. We did dabble with optional two-factor authentication, and we brought in federated identity. And then very quickly after, it's like, look, we've got to make this mandatory. If people won't proactively sign up for it, we have to force it. The assets that we manage are just too valuable to not be protected. And as you can see, we've got a whole host of things that we've been doing, and obviously lately, just last year we launched the Subdomain Monitoring.