In Emily M. Stark's Certificate Transparency is really not a replacement for key pinning, Stark asks a good question:

[...] what is a domain owner supposed to actually do if they find a malicious certificate for their domain in a CT log? [...]

I don't have an answer to this, but we can ask a related question: what does it mean if your CT log monitoring turns up a TLS certificate for your domain that you don't know about?

I think that there are four things that it could mean, which I'll order from the least likely to the most likely. First, the Certificate Authority could be compromised and the attacker has chosen to burn that compromise (and probably the entire CA) in order to get a TLS certificate for your host or domain. This is probably the least likely option but the most valuable thing for the overall TLS ecology to detect.

('Compromised' here includes the government of the CA's jurisdiction turning up with an order for it to issue some TLS certificates.)

Second, the CA's processes for issuing TLS certificates could have problems that have been exploited (deliberately or accidentally), what's sometimes called a 'mis-issuance'. Historically mis-issuance has come in all sorts of forms, including trying to trick the CA about your identity (corporate or otherwise). Mis-issuance is a CA issue that the CA is going to have to fix right away once it's detected, complete with officially revoking the mis-issued TLS certificates (for all the good that will or won't do). Mis-issuance is tragically still not completely stamped out.

Third, the CA's attempt to do domain validation could have been fooled through technical means like BGP route hijacking, which apparently is something that has happened (or been attempted) repeatedly (also). You might call this mis-issuance, but here the flaw is outside of the CA's processes and code, although the CA still needs to change its processes to make this harder (or impossible).

Fourth and most likely, some elements of your domain have been compromised by an attacker who used those elements to pass domain validation and get a TLS certificate. Depending on how the CA in question does domain validation, this could be DNS, email (possibly only specific addresses), a particular host, or a firewall. To a CA doing domain validation, an attacker with sufficient control over the right thing looks just like you requesting a real TLS certificate. Unfortunately this is both probably the most common and the least likely to be dealt with in a useful way unless you're a big site, since ordinary TLS certificate revocation is still not very useful as far as I know.

(The major browsers are working to change this situation with some clever tricks and so life may be better someday. Today, if you're an ordinary site I think TLS certificate revocation only affects people using Firefox who haven't disabled OCSP checks.)

Some bad TLS certificates may point to signs of multiple things. For example, if you have a CAA DNS record but an unexpected TLS certificate is issued for your domain from a CA that's not listed, you could have both an attacker in control of your host and a CA with a mis-issuance problem (that they're not properly checking CAA records).

(I may have missed more possibilities. I'm deliberately excluding all varieties of 'it was basically legitimate activity inside your organization', which in some cases can look very much like an attacker in action.)