It has been almost a year since the infamous SolarWinds supply chain attack rocked the software supply chain. Well, almost a year since it has been discovered that the threat actor had been in SolarWind’s network long before that. The threat actor is known by many names: Nobelium, UNC2452, Dark Halo, Cozy Bear, StellarParticle and more. For the rest of this blog, I’ll refer to them as Nobelium.
The Solarwinds supply chain attack was the most visible attack that Nobelium perpetrated, but it wasn’t their only one. There are indications that they have been formed in 2008 and actively have been compromising organizations since at least 2010. Even since the Solarwinds supply attack they have been busy perpetrating nefarious deeds such as running a wide-scale spear-phishing campaign, using their ever-evolving custom-made malware. An interesting piece of post-exploitation malware that Nobelium developed was recently discovered. It is called FoggyWeb. Among other things, it exfiltrates the decrypted token-signing certificates and token-decryption certificate from ADFS. Talk about scary!
A recently discovered DNS hijacking campaign was using malware called Tomiris which has many similarities to the Sunshuttle second-stage backdoor used in the Solarwind’s supply chain attack. This suggests (but not proves) a link to Nobelium. The DNS hijacking campaign was targeted at a CIS member state, mostly for redirecting webmail logins to a threat actor’s-controlled server for the purpose of gathering credentials as well as pushing malware. DNS hijacking is a commonly used technique by threat actors, though not all DNS hijacking techniques are created equal. The technique used in this campaign is particularly dangerous. Why? It’s all in the certificates! (and, of course, the scope).
What is DNS Hijacking?
In short, it’s manipulating the DNS queries of a client, usually with the goal of forwarding the client’s traffic to a threat actor-controlled server instead of the legitimate server. The intercepted traffic can then be used to harvest credentials and personal information, push malware or other nefarious purposes. There are a variety of different techniques for DNS hijacking which I’ll highlight below:
Client-side: This generally involves malware, though can also be accomplished by social engineering. The malware could change DNS queries/responses, change the HOSTS file or configure the OS to use a threat actor-controlled DNS resolver. With any of these in place, the client will resolve specific DNS queries to a malicious server. The scope of client-side DNS hijacking is limited to only compromised clients and for any domain.
Network-side: Most clients get their IP configuration through DHCP, including which DNS Resolver to use. A compromised DHCP Server can be configured by the threat actor to provide malicious DNS Resolvers. Another network-side vector is compromising the local DNS Resolver to respond with malicious responses. Yet another way to pull off network-side DNS hijacking is by creating a threat actor-controlled network, usually a WiFi network with the same name as the target’s WiFi network, or a publicly accessible WiFi network (FreeWifi, Starbucks, MyAiportWifi, etc) hoping a client will connect to it. The scope of network-side DNS hijacking is limited to only the network that has been compromised and for any domain.
Man-in-the-middle: Also called MITM, man-in-the-middle refers to the threat actor being inline with the target’s network traffic and having the ability to inject traffic. In case of DNS hijacking, the threat actor has to be inline with the DNS queries and responses. The threat actor will inject fake responses to legitimate DNS queries, resolving specific queries to a threat actor-controlled server. The scope of MITM DNS hijacking is either limited to specific clients or a network for any domain, depending on where the
Server-side: DNS is built hierarchically with Root Servers at the top, Top Level Domains (.com, .net, .nl etc) at the next level and Second Level domains for customer domains (venafi.com, jetstack.io etc). Attacks on the Root Servers or Top Level Domains servers are rare (but not unheard of). Most of the attacks will focus on the Authoritative DNS servers for a specific domain. The Authoritative DNS servers for a domain are the source of truth for all DNS queries for that domain (www.venafi.com, venafi.com, marketplace.venafi.com, etc). No matter how many DNS Resolvers are in the path, the final answer always come from an Authoritative DNS server (or from a previously cached response).
If an Authoritative DNS server gets compromised a threat actor can change all DNS records for that domain, create new DNS records and delete existing ones. Using these options, it’s easy to manipulate clients to go to the threat actor-controlled servers. Alternatively, if a threat actor has access to the domain’s registrar’s account, they can change the SOA (Start of Authority) record. SOA records are what is used to determine which DNS servers are authoritative for a specific domain. The threat actor can change the SOA record to point to a threat actor-controlled DNS server, which makes the threat actor's server the source of truth for that domain, controlling all DNS responses for that domain. The scope for (authoritative) server-side DNS hijacking is worldwide for that specific domain.
SSL/TLS Certificates and Their Prevalence on the Dark Web
The Threat Actor’s Methods
The DNS hijacking method used by Nobelium in the recently uncovered campaign was server-side, which is the most dangerous variation. And more specifically, by changing the SOA record of the target domain. Aside from the scope of this method, which is every client worldwide, it also poses another threat. The possibility that a threat actor could use a publicly trusted certificate, which is exactly what the Nobelium did in this instance.
Certificates are used by the client to verify the authenticity of the server. If the certificate is signed by a trusted Certificate Authority (CA), the client assumes the server is legit. For this reason, getting a certificate that is signed by a trusted CA always includes the CA verifying ownership of the domain. The most basic version of this is domain validation using one of different methods. Example methods are creating a specific DNS CNAME record, creating a specific DNS TXT record, emailing the domain owners listed in the WHOIS record or hosting a specific file at a specific location on the domain's website. Especially creating a TXT or CNAME DNS record is easy when the threat actor controls the Authoritative DNS servers.
In this case, the threat actor used the well-known free to use CA Let’s Encrypt to obtain certificates. The threat actor was interested in harvesting credentials as well as pushing malware. With control of the authoritative DNS servers as well as valid publicly trusted certificates, they could now direct users trying to login into their webmail the malicious servers without the end users noticing anything wrong.
The User’s Experience
The absence of a valid publicly trusted certificate would indicate to a user that something was wrong. In fact, the browser would tell them. All current browsers warn the user if the certificate is not publicly trusted, if the name doesn't match or in case of any other problems. The browser will also show if the website is using HTTP instead of HTTPS. DNS hijacking without the ability to present a valid certificate would have been noticed by users and administrators and action could’ve been taken soon after the DNS hijack.
Left: Normal behavior of visiting a webmail portal with a valid cert. Right: the same webmail portal but with a self-signed (i.e., not trusted) certificate.
However, if the threat actor is using a valid publicly trusted certificate a user would not be able to tell the difference. It’s possible to see the certificate details, but it requires effort and specific knowledge. Almost no one will check the certificate of the sites they visit. I know I don’t check unless I am troubleshooting or testing. With no one noticing that traffic was being forwarded to a threat actor-controlled server, the attack went unnoticed.
Left: An un-compromised webmail portal. Right: A webmail portal running on a compromised server with a threat actor owned certificate. Both images appear to be identical.
Left: Non-LetsEncrypt. Right: LetsEncrypt. The details show that the certificates used are indeed different, but this is not apparent to a user.
How to protect against this type of attack?
If a threat actor controls the Authoritative DNS servers of your domain(s), there is a lot of malicious behavior they can get up to. In the real-life campaign we’re exploring in this blog, the threat actor focused on internal users accessing their webmail. But with total control it’s also possible to focus on external users, getting their credentials, PII, credit card information and more. Or compelling them to install malware. The possibilities are endless.
Securing your DNS servers as well as your account with your domain registrar has priority. However, no single security measure is bulletproof. A disgruntled employee of your company (or the registrar) may be malicious. Or the domain registrar can be compromised. A zero day vulnerability might be exploited on your DNS servers. There are still attack vectors that could allow a threat actor to gain full control of your domain. As with all IT security, a layered strategy is the best approach.
Another high priority is to monitor your certificates and the certificates used by all your assets. A proper certificate monitoring solution would have noticed that a certificate was changed for the webmail portal, alerting an admin to the unauthorized change. This would trigger an investigation and would limit exposure time dramatically. In the real-life campaign, the threat actor hijacked domains for weeks at a time. With proper monitoring this would've been limited this to less than a day.
How can Venafi help?
Venafi provides a comprehensive platform for Machine Identity Management, which includes full lifecycle management of certificates. Venafi has two products that will alert if a certificate that you control has changed to an unmanaged certificate: TLS Protect (self-hosted on-premises) and Venafi as a Service (cloud native service). Both offer continuous monitoring of certificates being used on your domains.
Get a 30 Day Free Trial of TLS Protect Cloud, Automated Certificate Management.
Related Posts