If you have a full MITM (you can do anything you like with all traffic to/from the target), you just do your own ACME validation with the target's domain without involving the target at all. Then you use that to MITM the SSL on any connections to the target (terminate SSL between the other side and your middlebox, then push the plaintext into your target, which is unaware anything has changed at all).
If the owner watches CT logs they will know about it (and you may need to jump through some more hoops once the target tries to renew their cert), but you get a lot of info in the meantime.
Sure, but this has nothing to do with ACME itself. The attack model here is "if the attacker is effectively in control of the domain, then they can demonstrate that control." That's a way stronger posture than being able to maliciously MITM a specific ACME session, which (I think) is what the original concern was.
However, even with the full MITM here, this attack assumes that the attacker can proxy plaintext to the host. I'm not aware of many sites that allow sensitive actions (e.g. logging in) over HTTP anymore.
(And, as you note, this is detectable via CT. But it's fair to point out that many/most smaller operators probably aren't bothering to monitor public CT logs for unexpected issuances.)
> The attacker could just proxy the plaintext by issuing HTTPS requests to the backend server instead of issuing HTTP requests.
Yes, assuming the target has HTTPS. The context I originally assumed was one where the target doesn’t yet have a certificate and is using ACME to obtain one.
Separate from that, I agree that an attacker with the ability to demonstrate domain control can subvert issuance in a way that only CT, stapling, and other “post hoc” methods can detect.
If the owner watches CT logs they will know about it (and you may need to jump through some more hoops once the target tries to renew their cert), but you get a lot of info in the meantime.