You can only lock the malware server out of the loop if you use a secure channel like HTTPS. However, browser implementations and SSL validation companies focus mostly on proving that the server endpoint is trustworthy, not whether the client endpoint is trustworthy (or a human). Without client authentication, there is no effective difference between computer rerouting human proof-of-work and an indifferent human spammer using a computer to post the selfsame message.
You would need the equivalent of VeriSign/GeoTrust client certification service but free, pseudonymous and only caring that you are a human. At this stage, I haven't heard on any service like that. A web-of-trust certification chain might be another approach; but no robust, populous or frankly trustworthy web has been established yet.
A micro-payment escrow could also work but raising the deterrent high enough to counteract the value proposition of spam, would lockout or discourage many users regardless of the escrow feature - for how many of us trust server admins and site moderators enough to escrow spam fines?
Best answer at this point is either don't worry about CAPTCHA hijacking or routinely fiddle with the AJAX/HTML post interface in a fashion that requires the spammer's human intervention to re-code.
Essentially your human adjustment of site API vs. spammer's incentive to adjust their API for your site. You might want to lower these incentives through spam filtering, etc.