If this is possible, what is stopping a malicious file from adding an entry to \etc\hosts that points example.com to a phishing clone of a website?

Usually, the browser warns you that the common name on the certs does not match up, but if you can change a SAN of the malicious website to example.com, then would browsers allow it. Is this possible?

  • 1
    This isn't possible because CAs verify that the requestor owns all the domains within the Subject Alternate Name
    – paj28
    Oct 24, 2023 at 10:59
  • 1
    This verification is typically done by some method of domain validation. See en.wikipedia.org/wiki/Domain-validated_certificate for more info.
    – mti2935
    Oct 24, 2023 at 11:53

2 Answers 2


... what is stopping a malicious file from adding an entry to \etc\hosts that points "example.com" to a phishing clone of a website?

Modifying /etc/hosts so that it affects the victim means that this modification needs to be done at the system of the victim themselves, i.e. it has no effect if this change is just done at the attackers system.

If the attacker has the privileges to alter the hosts file at the victims system then likely other harm can be done too, like adding an attacker controlled certificate authority as trusted to the browsers on the system. Once this is done the attacker can issue whatever certificates they like with their own certificate authority, i.e. there is no need to get such certificates from a publicly trusted CA. This makes it possible that the attacker uses certificate issued for another domain but trusted by the victim.

In other words: TLS/HTTPS can no longer provide the usual protection if the attacker has managed to compromise the victims system.

Note that there are other methods to manipulate DNS lookups which don't require compromise of the victim system. The attacker might for example control the DNS server used by the victim or might be able to hijack DNS queries and answer these themselves (DNS spoofing). Such attacks can be achieved if the attacker has sufficient control over the network used by the victim. In this scenario the attacker has no control over the trusted root CA used by the victim. The attacker can also not get a certificate for a foreign-controlled domain from a public CA, unless they manage to either compromise this domain or compromise the CA.


Is it possible to get a SSL certificate with a Subject Alternate Name of a different website?

Yes, it is possible, but a legitimate certificate authority will only issue such a certificate if the owner of the certificate signing request can prove ownership of the other domain. This Is the same requirement that is applied for every domain listed in the certificate (or indeed for any kind of subject name for any certificate, not just domains). That is, it is always the responsibility of the CA to verify that every subject in a CSR is, or is owned by, the party requesting the certificate. A public-facing certificate authority that issues a fraudulent certificate - that is, one for a subject (domain or otherwise) that the requester does not own - faces significant risk of being marked untrusted by major browser/TLS library/OS vendors, especially if they didn't immediately both revoke the fraudulent certificate and publicly own up to the failure and how they'll avoid it in the future. Such a loss of trust would immediately cause them to lose all their business (since all their current and potential clients would instead need to get certificates from elsewhere if they wanted them to be trusted), an existential risk for any company. It really is a "you had one job" scenario.

what is stopping a malicious file from adding an entry to \etc\hosts that points "example.com" to a phishing clone of a website?

To directly answer the question as asked: OS file system access controls, a.k.a. file permissions. Unprivileged processes are not allowed to edit or replace the HOSTS file. If you run a malicious privileged process on your machine, then of course it can do anything. At that point, it's game over; you have violated the basic security premise of all major operating systems. (It's possible to put attempts at mitigations in place - such as prompting the user for confirmation before writing a change to that file, or antivirus attempting to detect this activity and flag the file as malicious before it runs - but the first can be circumvented by a privileged process anyhow, and the second can be circumvented by obfuscation. You fundamentally can't prevent a sufficiently privileged malicious program from doing anything that the user themselves is permitted to do, that's just how computers work.)

To answer this in the context of the overall question, it shouldn't matter, because spoofing HOSTS or modifying DNS is neither necessary nor sufficient to bypass TLS. If the attacker has a trusted fraudulent certificate (or the private key to the legitimate certificate), then there are usually easier ways to employ it than modifying the HOSTS file, such as DNS spoofing or man-in-the-middle attacks on the network e.g. by compromising a router, proxy, or VPN server, or ARP spoofing the victim's local network. None of those attacks require any code execution on the victim's machine at all. If the attacker does not have a fraudulent certificate or the legit cert's private key (or the fraudulent certificate is not from a trusted CA), then spoofing the domain's IP (via HOSTS file, DNS, or network interception) won't achieve anything beyond making it difficult for the victim to access that domain; the client will either reject whatever certificate it receives, or the attacker will be unable to prove possession of the certificate's corresponding private key and complete the TLS handshake.

On the other hand, if the attacker has the necessary permissions to modify the HOSTS file, they have all the access needed to carry out other attacks that are at least as harmful. For example, the attacker could hook the TLS library to see and potentially modify all traffic sent or received in plain text, or install its own private CA certificate as a trusted CA and issue fraudulent certificates for arbitrary sites from it, or modify the TLS library to not perform certificate validation, or simply monitor everything the user does or sees on the system (and potentially inject their own actions or content). All of those require essentially the same permissions as modifying the HOSTS file.

if you can change a SAN of the malicious website certificate presented to the browser to "example.com"

Edited because websites don't have SANs, certificates do, and any certificate can be presented for any domain if the attacker either controls the server or intercepted the request (just, in generally all but one of such combinations, the client would reject the certificate).

Editing a certificate will break the signature of the certificate authority, rendering the certificate invalid. Any conformant TLS client will reject such a certificate. To fix the signature, you'd either need to find a collision in the signing scheme (this is why signing schemes based on broken hash functions like MD5 and SHA1 are no longer trusted for certificates, or most other purposes) or obtain the private key of a certificate authority (which is an even worse existential risk than issuing a fraudulent certificate; CAs have to be extremely careful not to expose their private key if they want anybody to trust their certificates).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .